[Insight-users] Re: incorrect z-spacing in GDCM reading

[Li, George (NIH/NCI)]

Mathieu and Jim:

There is a redundant information in the dicom header, which is the 
slice thickness (0018,0050) that you could use to get z spacing 
information from a single image slice. Otherwise, you have to get 
the spacing information from at least 2 image slices. 

The image position and image orientation are the basic parameters 
necessary for the correct relationship among slices.

Regards,

George



-----Original Message-----
From: Mathieu Malaterre [mailto:mathieu.malaterre at kitware.com] 
Sent: Wednesday, May 11, 2005 5:42 PM
To: Mathieu Malaterre
Cc: insight-users at itk.org; Miller, James V (Research)
Subject: Re: [Insight-users] Re: incorrect z-spacing in GDCM reading


Ok I meant Image Position Patient can be computed from 
Origin+Spacing+ImageOrientation

Mathieu

Mathieu Malaterre wrote:
> Jim,
> 
>     BTW I am not up to date, but is the ImageOrientation completely
> integrated ? If so then Image Position Patient can be computed at each 
> frame thanks to ImageOrigin + ImageOrientation. So even when creating an 
> image from scratch we should now be able to write valid DICOM file.
> 
> Mathieu
> 
> Miller, James V (Research) wrote:
> 
>> Mathieu,
>> We have a use case where this happens that we were discussing today.
>> If your create DICOM images from scratch (i.e. not reading a DICOM but 
>> are producing a DICOM) or you are not sharing an instance of 
>> GDCMImageIO between the input and the output, then
>> the z position in ImagePositionPatient will be incorrect.
>>
>> The problem is that the ImageSeriesWriter is given an 3D image.  It
>> then uses an
>> ImageFileWriter to write each slice (a 2D image). When ImageFileWriter 
>> only "sees"
>> a 2D image, therefore there is not 3rd coordinate to give to 
>> GDCMImageIO to set the Z position of the image position patient.
>>
>> You could invision a solution where information is passed to
>> GDCMImageIO via the meta data dictionary.  While GDCMImageIO does take 
>> information from the dictionary, some of the tags are always 
>> overridden by GDCMImageIO. It is some of these tags that keep you from 
>> specifying the correct Z coordinate of the ImagePositionPatient.
>>
>> As a temporary workaround we commented out where GDCMImageIO sets
>> ImagePositionPatient
>> and assume it was set in the meta data dictionary.
>>
>> Jim
>>
>>
>>
>> -----Original Message-----
>> From: insight-users-bounces+millerjv=crd.ge.com at itk.org
>> [mailto:insight-users-bounces+millerjv=crd.ge.com at itk.org]On Behalf 
>> Of Mathieu Malaterre
>> Sent: Wednesday, May 11, 2005 4:45 PM
>> To: Hxsham Fire
>> Cc: insight-users at itk.org
>> Subject: Re: [Insight-users] Re: incorrect z-spacing in GDCM reading
>>
>>
>> Hxsham
>>
>>     What are you reporting is rather scary. Could you tell us which
>> version of ITK are you using ? Also on which example did you base your 
>> code ? The fact is that this is tested nightly:
>>
>> $ ctest -R itkGDCMSeriesReadImageWrite -V
>>
>> This create three new files in Testing/Temporary/. Then all you need
>> to check is that 'Image Position Patient' is correct:
>>
>>
>> $ for i in `ls Testing/Temporary/*.dcm`; do
>> ./bin/DicomImageReadPrintTags $i; done | grep "Image Position"
>>
>> Image Position Patient = -112\ -21.688\ 126.894
>> Image Position Patient = -112\-20.2729\ 127.641
>> Image Position Patient = -112\-18.8578\ 128.388
>>
>>     Which looks good to me...
>>
>> HTH,
>> Mathieu
>>
>> Hxsham Fire wrote:
>>
>>> George and Mathieu,
>>>
>>> This looks very similar to the problem I was having
>>> with ITK...
>>> The dicom series reader was reading the slices fine,
>>> and the volume had correct spacing... however after I
>>> write the series using the dicom series writer and try
>>> to read it back again, for further modification is
>>> when the z spacing fails, and the slices are compacted
>>> in the z direction, and it is most noticable if I try
>>> to rotate that image...  also I noticed that all the
>>> slices have the same z coordinate of the origin in the series 
>>> written by the dicom writer (that is field
>>> 0020|0030) in the dicom directory, and it is the
>>> values of the last slice in the original series that
>>> is written on all the slices in the output series.
>>>
>>> Hxsham
>>>
>>> ----------------------------------------------------
>>> ----------------------------------------------------
>>>
>>> George,
>>>
>>>        Your code looks fine. The algorithm for
>>> finding the z spacing is kind of tricky. So I am wondering if:
>>>
>>> 1. Your images might not have proper 'Image Position Patient' / 
>>> 'Image Orientation Patient'
>>>
>>> 2. If they have, maybe gdcm is not able to parse the
>>> string properly.
>>>
>>> Could it be possible that you send me at least two
>>> images from this dataset ?
>>>
>>> If not, you'll have to turn the code to be more
>>> verbose in particular when entering the function:
>>>
>>>
>>>     gdcm::SerieHelper::ImagePositionPatientOrdering
>>>
>>> Thanks,
>>> Mathieu
>>>
>>>
>>>
>>>        
>>> Yahoo! Mail
>>> Stay connected, organized, and protected. Take the tour: 
>>> http://tour.mail.yahoo.com/mailtour.html
>>>
>>> _______________________________________________
>>> Insight-users mailing list
>>> Insight-users at itk.org 
>>> http://www.itk.org/mailman/listinfo/insight-users
>>>
>>
>>
>> _______________________________________________
>> Insight-users mailing list
>> Insight-users at itk.org 
>> http://www.itk.org/mailman/listinfo/insight-users
>>
> 
> _______________________________________________
> Insight-users mailing list
> Insight-users at itk.org 
> http://www.itk.org/mailman/listinfo/insight-users
> 

_______________________________________________
Insight-users mailing list
Insight-users at itk.org http://www.itk.org/mailman/listinfo/insight-users