[Insight-users] Re: incorrect z-spacing in GDCM reading
Mathieu Malaterre
mathieu.malaterre at kitware.com
Thu May 12 11:22:34 EDT 2005
Jim,
I was looking at the ImageSeriesReader and during the reading it is
setting ITK_ImageOrigin in the metadata dictionary. What do you think
then if the ImageSeriesWriter would set a ITK_ImagePosition in the
metadata dictionary as it goes.
Later on the GDCM writer would use ITK_ImagePosition only if no Image
Position Patient is found in the metadata dictionary...
My 2 cents
Mathieu
Miller, James V (Research) wrote:
> Mathieu,
>
> Even with the ImageOrientation information, we will have the problem
> of transitioning 3D information from a 3D image down to a 2D image
> for a single slice. We just do not have a methodology for passing
> the extra information down from the SeriesWriter to the FileWriter
> to the ImageIO.
>
> Jim
>
>
>
> -----Original Message-----
> From: Mathieu Malaterre [mailto:mathieu.malaterre at kitware.com]
> Sent: Wednesday, May 11, 2005 5:40 PM
> To: Miller, James V (Research)
> Cc: insight-users at itk.org
> Subject: Re: [Insight-users] Re: incorrect z-spacing in GDCM reading
>
>
> 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
>>
>
>
>
More information about the Insight-users
mailing list