[Insight-users] BUG in DICOMParser

[Miller, James V (Research)]

When reading volumes, ITK typically uses the ImagePositionPatient
fields to determine slice spacing (since any other fields are unreliable).

Jim

-----Original Message-----
From: jolinda [mailto:jolinda at darkwing.uoregon.edu]
Sent: Wednesday, March 31, 2004 12:11 PM
To: jean-michel.rouet at philips.com
Cc: insight-users
Subject: RE: [Insight-users] BUG in DICOMParser


Hi JM,

Now I understand. (0018, 0050) (Slice Thickness) is a type 2 required
element. That means it's required to be present, but is allowed to have
no value and a value length of 0.

If you are trying to read a single slice into a 2D image, I think ITK
ought to be able to do that without knowing the slice thickness. If it's
failing, I'd say that's a bug.

If you're trying to read a number of slices into a 3D volume, it depends
on how ITK calculates the voxel size along the slice axis. It really
shouldn't use the slice thickness here, either, but it might (and
probably does). If this is what you are trying to do, try MRIConvert. It
doesn't use the slice thickness for this, but calculates the spacing
between adjacent slices from the Image Position Patient and Image
Orientation Patient elements. I'd like to know if it still fails on your
images.

The third possibility is that you're trying to read a single slice into
a 3D volume. This will (and should) fail, because there is no
information available about the voxel size in the third dimension.

Jolinda Smith
Lewis Center for Neuroimaging
University of Oregon
Eugene, OR  97404
email: jolinda at uoregon.edu
MRIConvert: free Windows software for converting DICOM files to volume
formats
http://lcni.uoregon.edu/~jolinda/MRIConvert


> -----Original Message-----
> From: jean-michel.rouet at philips.com 
> [mailto:jean-michel.rouet at philips.com] 
> Sent: Wednesday, March 31, 2004 1:31 AM
> To: jolinda at uoregon.edu
> Subject: RE: [Insight-users] BUG in DICOMParser
> 
> 
> On 30/03/2004 19:32:53 jolinda wrote:
> >Hi Jean-Michel,
> >
> >It's pretty common to have elements with zero length, so 
> that shouldn't 
> >be a problem. However, there is no group 24 in the standard, 
> or in your 
> >file. I don't see anything obviously strange about your file, so I 
> >agree that something must be wrong with DICOMparser.
> 
> 
> Hi Jolinda, thanks for your quick answer,
> 
> When I wrote group=24 it was in decimal, not in hexa. Thus 
> group =0x18, 
> Element=0x50 if you prefer.
> According to the standard I see: 
>         (0018,0050) AN S -> Slice Thickness #mm
> I don't know what AN S means, probably S means it is a string 
> ? ... This tag was recognized as a VR_DS (Decimal String). 
> Then length is read 
> as 0 !!! Is that normal that the slice thickness is given as 
> a 0 length 
> string ?
> is there a default value to use then ?
> This is all but clear to me.
> 
> JM
> 
> 


_______________________________________________
Insight-users mailing list
Insight-users at itk.org
http://www.itk.org/mailman/listinfo/insight-users