[ITK-users] [ITK] Misunderstood ResampleDICOM example behaviour

Dr Nick Patterson pattersonnp.work at gmail.com
Tue Apr 15 10:48:59 EDT 2014


Hi, 

 Thanks for your input. I was always led to believe that the SliceLocation tag was not reliable (in that it is Type 3, an optional tag so is not always present). Therefore I assumed that using the 3rd element of the patient position tag was always the way to go in determining the Slice Spacing. It could indeed be something to do with the inversion between slice location and patient position, so this may well be something to look at.

However, I have just this second realised that I am running 4.5.1….. so I shall pull the latest version from the git repo.

Many thanks for your help.



On 15 Apr 2014, at 15:44, Guillaume Lemaître <g.lemaitre58 at gmail.com> wrote:

> I don't know if it is relevant but the field SliceLocation is inversed between the two headers. GDCM is reorganizing the slice itself and can modify the origin and the orientation itself:
> Extract Image Orientation & Image Position from DICOM images, and then calculate the ordering based on the 3D coordinate of the slice
> Regarding the spacing, it seems that the value given in Matlab and by the reader are the same [.9766 .9766]. However, you would need to give probably the adjacent slice to know about the z spacing which is not appearing inside the header. You probably did it, but what is the z spacing when checking the image position dicom tag between two PET DICOM images. Is the spacing of 3.5 mm or 1 mm?
> 
> Cheers,

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-users/attachments/20140415/61fae097/attachment.html>


More information about the Insight-users mailing list