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

Mathieu Malaterre mathieu.malaterre at kitware.com
Thu May 12 09:33:37 EDT 2005


Looks like commit was successful:

http://www.itk.org/Testing/Dashboard/20050512-0500-Nightly/Update.html

HTH
Mathieu

Li, George (NIH/NCI) wrote:
> Mathieu:
> 
> Have you committed the change of GDCM? I got the CVS update yesterday 
> afternoon, it seems not. But, I cannot connect to ITK CVS this morning. 
> Is there something going on at the server?
> 
> Regards,
> 
> George
> 
> 
> -----Original Message-----
> From: Miller, James V (Research) [mailto:millerjv at crd.ge.com] 
> Sent: Thursday, May 12, 2005 8:36 AM
> To: Li, George (NIH/NCI); Mathieu Malaterre
> Cc: insight-users at itk.org
> Subject: RE: [Insight-users] Re: incorrect z-spacing in GDCM reading
> 
> 
> George, 
> 
> We've moved away from using slice thickness for the z spacing because so
> many of the datasets we use are either:
> 
> (Assuming CT here...)
> 
> 1. Thicker than they are spaced (i.e. the slices technically overlap). 2.
> Spaces much farther than there thickness.  For drug trial applications with
> imaging endpoints, there is a limit on the amount of radiation 
> the subjects can be exposed. We frequently get image sets that have 2.5mm
> thick slices spaced every 20mm.
> 
> The only safe method we have found is determining slice spacing from
> adjacent slices. We actually assume the spacing does not 
> change through the series.
> 
> Jim
> 
> -----Original Message-----
> From: Li, George (NIH/NCI) [mailto:ligeorge at mail.nih.gov]
> Sent: Thursday, May 12, 2005 7:42 AM
> To: 'Mathieu Malaterre'; Miller, James V (Research)
> Cc: insight-users at itk.org
> Subject: RE: [Insight-users] Re: incorrect z-spacing in GDCM reading
> 
> 
> 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
> 



More information about the Insight-users mailing list