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

Thu May 12 08:57:43 EDT 2005

Jim:

Interesting! There are actually inconsistent. All I can think of 
for an explanation is the fact that slice thickness is type 2 and 
image position and image orientation are type 1, therefore type 1 
should be used and the type 2 is then a "backup".

I wonder if the slice thickness is an "input" number by operator, 
while the others are recorded directly from the scanner.

Thanks for the comment.

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