[Insight-users] BUG in DICOMParser
Miller, James V (Research)
millerjv at crd.ge.com
Thu, 1 Apr 2004 09:41:24 -0500
I checked in a patch to Insight/Utilities/DICOMParser/DICOMAppHelper.cxx
that checks the length passed to the PixelSpacingCallback() and
SliceNumberCallback(). Can you give this a try?
(We do not use the (0x0020, 0x0030):Image_Position field, so a 0 length
record there shouldn't affect ITK).
-----Original Message-----
From: jean-michel.rouet at philips.com
[mailto:jean-michel.rouet at philips.com]
Sent: Thursday, April 01, 2004 3:39 AM
To: Miller, James V (Research)
Cc: insight-users at itk.org
Subject: RE: [Insight-users] BUG in DICOMParser
Yes, but here, The crash was happening as soon as I was only parsing a
directory with the itk::DICOMSeriesFileNames::GetSeriesUIDs() method.
DicomImageViewer from ITKApplications is also crashing on the same 2D
image
In that directory there is a 2D image where the slice thickness has no
value and a length of zero.
This is not checked by ITK, and then the CallbackFunction
"DICOMAppHelper::PixelSpacingCallback()" is called with a null pointer 5th
argument (unsigned char *val), which crashes!!!
I also found that, the same file also crashes further on
DICOMApphelper::SliceNumberCallback() for another field being zero length.
This should definitely not be the case. At least, I was expecting that an
error message appears?
Here are some of the DICOM headers of the image as given by MRIConvert:
(0008, 0000) IDENTIFYING_GROUP_LENGTH UL 4 546
(0008, 0001) LENGTH_TO_END UL 4 531290
(0008, 0005) CHARACTER_SET CS 10 ISO_IR 100
(0008, 0008) IMAGE_TYPE CS 28
DERIVED\SECONDARY\AXIAL\MPR
(0008, 0010) unknown LO 12 ACR-NEMA
2.0
(0008, 0012) unknown DA 8 20031023
(0008, 0013) unknown TM 14
153349.234000
(0008, 0014) unknown UI 20
1.3.46.670589.5.2.14
(0008, 0016) SOP_CLASS UI 26
1.2.840.10008.5.1.4.1.1.2
(0008, 0018) SOP_INSTANCE UI 48
1.3.46.670589.5.2.13.2158149747.997947019.566239
(0008, 0020) STUDY_DATE DA 8 20010815
(0008, 0021) SERIES_DATE DA 8 20010816
(0008, 0030) STUDY_TIME TM 14
133655.000000
(0008, 0031) SERIES_TIME TM 14
093535.915457
(0008, 0040) unknown US 2 0
(0008, 0041) unknown LO 12 MULTI_PLANAR
...
(0008, 1090) MODEL_NAME LO 8 Aquilion
...
(0018, 0000) ACQUISITION_GROUP_LENGTH UL 4 94
(0018, 0010) CONTRAST_AGENT LO 4 NONE
(0018, 0020) SCANNING_SEQUENCE CS 0
(0018, 0050) SLICE_THICKNESS DS 0 <--- THIS
IS CAUSING PROBLEMS TO ITK
(0018, 0060) unknown DS 0
(0018, 0080) REPETITION_TIME DS 0
(0018, 0082) INVERSION_TIME DS 0
(0018, 0083) NUMBER_OF_AVERAGES DS 0
(0018, 0084) IMAGING_FREQUENCY DS 0
(0018, 0085) IMAGING_NUCLEUS SH 0
(0018, 1020) SOFTWARE_VERSION LO 2
(0018, 5100) PATIENT_POSITION CS 0
...
(0020, 0000) RELATIONSHIP_GROUP_LENGTH UL 4 526
(0020, 000d) STUDY_INSTANCE_UID UI 32
1.2.276.0.14.200.1002.13.707230
(0020, 000e) SERIES_INSTANCE_UID UI 48
1.3.46.670589.5.2.13.2158149747.997947335.915903
(0020, 0010) STUDY_ID SH 4 744
(0020, 0011) SERIES_NUMBER IS 2 4
(0020, 0012) ACQUISITION_NUMBER IS 2 0
(0020, 0013) INSTANCE_NUMBER IS 0
(0020, 0030) IMAGE_POSITION DS 0 <--- I ALSO
THINK THAT THIS POSES PROBLEMS TO ITK
(0020, 0032) IMAGE_POSITION_PATIENT DS 32
6.329390\-222.656200\1702.990998
(0020, 0035) IMAGE_ORIENTATION DS 0
(0020, 0037) IMAGE_ORIENTATION_PATIENT DS 54
0.000000\1.000000\0.000000\0.000000\0.000000\-1.000000
(0020, 0050) LOCATION DS 0
(0020, 0052) FRAME_OF_REFERENCE_UID UI 54
1.2.392.200036.9116.2.2.2.1762552758.997851026.563005
(0020, 0060) LATERALITY CS 0
(0020, 0070) IMAGE_GEOMETRY_TYPE LO 6 Planar
(0020, 1040) POSITION_REFERENCE LO 0
...
Jolinda, MRI convert is able to display the image. Nevertheless, it is
part of a series (study 744/series 4) of independent slices (there are
slices of the thorax and sagital and coronal views in this serie) but it
is not a 3D volume!
MRIConvert 1.02v also crashes (sorry!) when either trying to convert the
serie, or viewing the series info (right click/series info). There is no
particular error message aside "Runtime Error! The application has
requested the Runtime to terminate it in an unusual way. blah blah blah".
JM
On 01/04/2004 00:16:02 "Miller, James V (Research)" wrote:
>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.
>