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

[Miller, James V (Research)]

I am thinking something like that will need to be done.  The same
with spacing. Not sure if there are any other 3D fields that should 
be passed along.



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


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