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

[Bill Lorensen]

I just looked at the example code. How are you running it? This example
generates a list of filenames to read. With DICOM, the file names are not
necessarily related to any order of the slices. For dicom files, the file
names can be completely arbitrary.



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

> 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
>>
>
>


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