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

[Mariana Bustamante]

Hi Bill,

Yes, I also thought that it might still work on Slicer, but the writer is
changing the IPP tag on the new file, so the origin is indeed changed.

I don't see any obvious problems on the example code, it's basically the
same code as ImageSeriesReadWrite2.cxx except it uses the classes
itkGDCMImageIO and itkGDCMSeriesFileNames to manipulate DICOM files.

If indeed there was a problem, I would guess it's on itkGDCMImageIO, in it,
the function Write uses the IPP tag from the output of
gdcm::Global::GetInstance() to set the origin of the new file. Could it be
that this is thought to work if the input is only one file, but not if it's
a series of files?

Regards,
--
Mariana


On Fri, Aug 9, 2013 at 1:41 PM, Bill Lorensen <bill.lorensen at gmail.com>wrote:

> 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/3ff8bd63/attachment.htm>