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

Fri Aug 9 11:11:09 EDT 2013

Hi Bill,

Yes, I understand that the files must be correctly ordered before writing
the new volume.

My code is attached, in it I am reordering the DICOM files by position and
trigger time and taking only the files that correspond to the heart-volume
I have chosen (the original files contain more than one volume of the heart
taken at different heartbeats). The ordering is done directly with
gdcm::Sorter, since I had problems adding restrictions
with itkGDCMSeriesFileNames (seems to be a common issue these days). I am
using my system's gdcm-2.3.0.

I also thought that maybe the sorting could be a problem, so I copied only
the files that correspond to one heart-volume in another folder and used
the example DicomSeriesReadImageWrite2.cxx without modifications on it. The
resulting DICOM file has the correct order of slices but still not the
correct IPP tag.

Regards,
--
Mariana

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

> 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/28da1579/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DicomSeriesReadImageWrite.cxx
Type: application/octet-stream
Size: 6100 bytes
Desc: not available
URL: <http://www.itk.org/pipermail/insight-users/attachments/20130809/28da1579/attachment.obj>