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

[Bill Lorensen]

Sorry, I just re-read your email. Please post the compete, modified example
source.

I'll try to take a look over the weekend...



On Fri, Aug 9, 2013 at 10:23 AM, Bill Lorensen <bill.lorensen at gmail.com>wrote:

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



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