FW: [Insight-users] Slice spacing of DICOM series
Andrew Li
andrew.li at synarc.com
Thu Sep 8 12:45:31 EDT 2005
Hi, Mathieu, Stephen and David:
This is an update.
I am in progress to have IPP (0020|0032) under our quality control.
After it is officially under QC, all data with this kind of problems
will be rejected. It may take awhile. I will let you informed.
Thanks a lot for your help. I really appreciated.
-Andrew
-----Original Message-----
From: David Clunie [mailto:dclunie at dclunie.com]
Sent: Wednesday, September 07, 2005 5:28 PM
To: insight-users at itk.org
Cc: Andrew Li; Mathieu Malaterre; Stephen R. Aylward; Luis Ibanez
Subject: Re: FW: [Insight-users] Slice spacing of DICOM series
Hi Andrew, Mathieu, Stephen, et al
Image Position (Patient) (0020,0032) is the only attribute that can be
relied on to determine the "reconstruction interval"
or "space between the center of slices".
If the distance between Image Position (Patient) (0020,0032) of two
parallel slices along the normal to Image Orientation
(Patient) (0020,0037) is not the same as whatever happens to be in the
DICOM Spacing Between Slices (0018,0088) attribute, then (0018,0088) is
incorrect, without question
As Mathieu notes, this is a known bug in some scanners.
When Slice Thickness (0018,0050) + Spacing Between Slices
(0018,0088) equals the computed reconstruction interval, then chances
are the modality implementor has made the obvious mistake of
misinterpreting the definition of
(0018,0088) to mean the distance between edges (gap) rather than the
distance between centers.
Conversely, I have never encountered an error like this in Image
Position (Patient) (0020,0032).
Further, one should never use Slice Location (0020,1041) either, an
optional and purely annotative attribute, though chances are that the
distance between the Slice Location
(0020,1041) values of two slices will match the distance along the
normal to the orientation derived from the position.
David
PS. Stephen, DICOM doesn't suck. Indeed, it is awesome.
The problem is morons who can't or won't read what is written in the
standard, and worse, modality engineers who don't test what they build.
:)
Andrew Li wrote:
> Hi, Mathieu:
>
> Thank for your information.
> I will forward the link to my boss too.
>
> -Andrew
>
> -----Original Message-----
> From: Mathieu Malaterre [mailto:mathieu.malaterre at kitware.com]
> Sent: Wednesday, September 07, 2005 3:42 PM
> To: Stephen R. Aylward
> Cc: Andrew Li; 'Luis Ibanez'; David Clunie
> Subject: Re: FW: [Insight-users] Slice spacing of DICOM series
>
> Hehe !
> I think I found the problem. Andrew I believe the problem you are
> seeing is what David Clunie reported here:
>
> http://groups.google.com/group/sci.med.radiology/msg/b2684d6a04fab7ac?
> dm
> ode=source&hl=en
> """
> Also be aware that there are buggy modalities that write the wrong
> value in (0018,0088) Spacing Between Slices, sending the spacing
> between the adjacent edges of slices rather between centers.
> """
>
> Therefore if you take Slice Thickness + Spacing Between Slices, you
> find indeed that spacing is 3 + 3 = 6mm. Which is coherent with IPP.
>
> Mathieu
>
> Stephen R. Aylward wrote:
>
>>Hi Andrew,
>>
>>DICOM sucks :)
>>
>>The images really looked more discontinuous than that and seemed to
>>span more space than 15 mm - hence my confusion. I must have a big
>>nose :)
>>
>>I understand your problem now.
>>
>>One option - I could see a member functions being added to
>>itkGDCMFileIO that would be called to specify what slice spacing
>
> method should be used
>
>>- that would be easy enough. The default would remain the same.
>>
>>Would you like to try to modify that file yourself so that it offers
>>the different spacing computation options?
>>
>>Thanks,
>>Stephen
>>
>>
>>
>>Andrew Li wrote:
>>
>>
>>>Hi, Steve:
>>>
>>>For this data, I know for sure that each slice is 3mm thick and there
>
>
>>>is no gap between adjacent slices.
>>>
>>>This data set has problems in the header.
>>>If you check Image-Position-Tag: 0020|0032, you get slice-spacing 6mm
>
>
>>>as ITK lib does; - for this data set, it happens to be wrong.
>>>If you check Spacing-Between-Slices-Tag: 0018|0088, you get
>>>slice-spacing 3mm; - for this data set, it happens to be right.
>>>
>>>My problem is that people here are using Spacing-Between-Slices-Tag:
>>>0018|0088 for quality control and they assume that processing
>>>0018|software
>>>is using the same tag: 0018|0088 to get slice-spacing.
>>>
>>>Thank.
>>>
>>>-Andrew CC: Mathieu
>>>
>>>-----Original Message-----
>>>From: Stephen R. Aylward [mailto:aylward at unc.edu] Sent: Wednesday,
>>>September 07, 2005 11:48 AM
>>>To: Andrew Li
>>>Cc: mathieu.malaterre at kitware.com
>>>Subject: Re: FW: [Insight-users] Slice spacing of DICOM series
>>>
>>>Hi,
>>>
>>>Okay - perhaps it is terminology.
>>>
>>>Are you saying that the centers of these slices are 3mm apart or that
>
>
>>>the slices have a thickness and the gap between the space occupied by
>
>
>>>two slices is 3mm?
>>>
>>>These slices look like 3mm thick with 3mm gap - which means 6 mm
>>>spacing. That interpretation is consistent with the dicom header.
>>>
>>>-125\-142.086\-31.8431
>>>-125\-143.18\-37.7426
>>>-125\-144.273\-43.6422
>>>-125\-145.366\-49.5417
>>>-125\-146.459\-55.4413
>>>=
>>>6 mm between the centers of the slices.
>>>
>>>This is what I get when I run dcmtk on it.
>>>
>>>s
>>>
>>>
>>>Andrew Li wrote:
>>>
>>>
>>>>-----Original Message-----
>>>>From: Andrew Li
>>>>Sent: Wednesday, September 07, 2005 10:07 AM
>>>>To: 'Stephen R. Aylward'
>>>>Cc: 'Mathieu Malaterre'
>>>>Subject: RE: [Insight-users] Slice spacing of DICOM series
>>>>
>>>>Hi, Stephen:
>>>>
>>>>This is an example: MRI data PD/T2 double echo, 82 slices, 41
>>>>slices for each echo.
>>>>
>>>> 0008,0060 Modality: MR
>>>> 0008,0070 Manufacturer: GE MEDICAL SYSTEMS
>>>> 0008,1030 Study Description: BRAIN 0008,103E Series
>>>>Description: AXIAL PD/T2 0008,1090 Manufacturer's Model Name:
>>>>GENESIS_SIGNA
>>>>
>>>> From the first slice of echo 1 (1/82):
>>>>
>>>> 0018,0088 Spacing Between Slices: 3 0020,0032 Image
>>>>Position (Patient): -125\-146.459\-55.4413
>>>> 0020,0037 Image Orientation (Patient):
>>>>1\0\0\0\0.983262\-0.182199
>>>> 0020,1041 Slice Location: -78.2157440186
>>>>
>>>> From the 2nd slice of echo 1 (3/82):
>>>>
>>>> 0018,0088 Spacing Between Slices: 3 0020,0032 Image
>>>>Position (Patient): -125\-145.366\-49.5417
>>>> 0020,0037 Image Orientation (Patient):
>>>>1\0\0\0\0.983262\-0.182199 0020,1041 Slice Location:
>
> -72.3161773682
>
>>>>There are different ways to derive slice-spacing:
>>>> 1) read from slicing Between Slices Tag: 0018|0088;
>>>> 2) derive it from Image Position Tag: 0020|0032;
>>>> 3) derive it from Slice Location Tag: 0020|1041;
>>>>
>>>>In most of cases, no matter which way used, the answer will be the
>>>
>>>
>>>same.
>>>
>>>
>>>>When there is a problem in the header, I believe that any tag could
>>>>be
>>>
>>>
>>>
>>>>wrong including 0018|0088.
>>>>
>>>>The problem for me (working on segmentation here in Synarc) is that
>>>>currently the tag: 0018|0088 is under QC but the tag: 0020|0032 is
>>>
>>>
>>>not.
>>>
>>>
>>>>I am going to check whether our QC team are willing to watch the
>
> tag:
>
>>>>0020|0032.
>>>>On the other hand, it would be helpful if you could add an option
>>>>for users to choose which method to use in DICOM series reader
>>>>class. In the meantime, I am using SetSpacing() to override the
>
> default.
>
>>>>Thank you very much!
>>>>
>>>>-Andrew
>>>>CC: Mathieu
>>>>
>>>>-----Original Message-----
>>>>From: Stephen R. Aylward [mailto:aylward at unc.edu]
>>>>Sent: Wednesday, September 07, 2005 6:32 AM
>>>>To: Andrew Li
>>>>Cc: Mathieu Malaterre; insight-users at itk.org
>>>>Subject: Re: [Insight-users] Slice spacing of DICOM series
>>>>
>>>>Hi Andrew,
>>>>
>>>>Are you saying, for your data, that the slice positions are wrong
>>>>for reconstructing the volume and that the slice thickness should be
>
>
>>>>used to space the slices?
>>>>
>>>>Stephen
>>>>
>>>>Andrew Li wrote:
>>>>
>>>>
>>>>
>>>>>Hi, Mathieu:
>>>>>
>>>>>Our previous ITK lib was built in June. I updated ITK code and
>>>>>built the ITK lib on Friday (9/2), but results were the same.
>>>>>
>>>>>Then, I took a closer look and the following were what I found:
>>>>> GDCM function GetZSpacing() is used to read slice spacing and
>>>>>it
>>>>
>>>>
>>>>is
>>>>
>>>>
>>>>
>>>>>correct.
>>>>> But at later time, in function GenerateOutputInformation() in
>>>>>file: itkImageSeriesReader.txx,
>>>>> slice spacing read from GetZspacing() is ignored, and
>>>>> slice spacing is actually derived from slice positions
>>>>
>>>>
>>>>of the first
>>>>
>>>>
>>>>
>>>>>slice and of the second.
>>>>>
>>>>>Unfortunately for us, when slice spacing and slice position are
>>>>>inconsistent in the headers, the latter is wrong for most of the
>
> time.
>
>>>>>For now, it is already good enough for us to just to know how slice
>
>
>>>>>spacing is derived in ITK package.
>>>>>Thank you very much for your help!
>>>>>-Andrew
>>>>>
>>>>>-----Original Message-----
>>>>>From: Mathieu Malaterre [mailto:mathieu.malaterre at kitware.com]
>>>>>Sent: Friday, September 02, 2005 10:11 AM
>>>>>To: Andrew Li
>>>>>Cc: insight-users at itk.org
>>>>>Subject: Re: [Insight-users] Slice spacing of DICOM series
>>>>>
>>>>>Andrew,
>>>>>
>>>>> Could you check you are using GDCM. GDCM was not the default
>>>>
>>>>
>>>>DICOM IO
>>>>
>>>>
>>>>
>>>>>factory until very recently.
>>>>>
>>>>> For more info on the ZSpacing you can check what is being done
>>>>
>>>>
>>>>in
>>>>
>>>>
>>>>
>>>>>gdcm/src/gdcmFile.cxx:File::GetZSpacing()
>>>>>
>>>>>HTH,
>>>>>Mathieu
>>>>>
>>>>>
>>>>>
>>>>>Andrew Li wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Hi,
>>>>>>
>>>>>>We use itk::ImageSeriesReader to read 3D MRI data set that is
>>>>>>stored as a (2D) DICOM series and then check the slice spacing in
>>>>>>slice direction as following:
>>>>>> ...
>>>>>> ReaderType::Pointer reader = ReaderType::New();
>>>>>> ...
>>>>>> double sliceSpacingInSliceDirection =
>>>>>>(reader->GetOutput()->GetSpacing())[2];
>>>>>> ...
>>>>>>
>>>>>>How slice spacing in slice direction is derived in
>>>>>>itk::ImageSeriesReader Class? It seems not from the tag: {0x0018,
>>>>>>0x0088} (spacing between slices).
>>>>>>
>>>>>>Please let me know. Thanks.
>>>>>>
>>>>>>-Andrew
>>>>>>
>>>>>>--------------------------------------------------------
>>>>>>
>>>>>>This email message is for the sole use of the intended
>>>>>>recipient(s)
>>>>>
>>>>>
>>>>>and may contain confidential and privileged information.Any
>>>>>unauthorized review, use, disclosure or distribution is prohibited.
>
>
>>>>>If
>>>>
>>>>
>>>>
>>>>>you are not the intended recipient, please contact the sender by
>>>>>reply
>>>>
>>>>
>>>>
>>>>>email and destroy all copies of the original message. If you are
>>>>>the intended recipient, please be advised that the content of this
>>>>>message
>>>>
>>>>
>>>>
>>>>>is subject to access, review and disclosure by the sender's Email
>>>>>System Administrator.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>--------------------------------------------------------
>>>>>>_______________________________________________
>>>>>>Insight-users mailing list
>>>>>>Insight-users at itk.org
>>>>>>http://www.itk.org/mailman/listinfo/insight-users
>>>>>>
>>>>>
>>>>>
>>>>>--------------------------------------------------------
>>>>>
>>>>>This email message is for the sole use of the intended recipient(s)
>>>>
>>>>
>>>>and may contain confidential and privileged information.Any
>>>>unauthorized review, use, disclosure or distribution is prohibited.
>>>>If
>>>
>>>
>>>
>>>>you are not the intended recipient, please contact the sender by
>>>>reply
>>>
>>>
>>>
>>>>email and destroy all copies of the original message. If you are the
>
>
>>>>intended recipient, please be advised that the content of this
>>>>message
>>>
>>>
>>>
>>>>is subject to access, review and disclosure by the sender's Email
>>>>System Administrator.
>>>>
>>>>
>>>>
>>>>>--------------------------------------------------------
>>>>>_______________________________________________
>>>>>Insight-users mailing list
>>>>>Insight-users at itk.org
>>>>>http://www.itk.org/mailman/listinfo/insight-users
>>>>
>>>>
>>>>
>>>>--
>>>>===========================================================
>>>>Dr. Stephen R. Aylward
>>>>Associate Professor of Radiology
>>>>Adjunct Associate Professor of Computer Science and Surgery
>>>>http://caddlab.rad.unc.edu aylward at unc.edu
>>>>(919) 966-9695
>>>>
>>>>--------------------------------------------------------
>>>>
>>>>This email message is for the sole use of the intended recipient(s)
>>>
>>>
>>>and may contain confidential and privileged information.Any
>>>unauthorized review, use, disclosure or distribution is prohibited.
>>>If you are not the intended recipient, please contact the sender by
>>>reply email and destroy all copies of the original message. If you
>>>are the intended recipient, please be advised that the content of
>>>this message is subject to access, review and disclosure by the
>>>sender's Email System Administrator.
>>>
>>>
>>>>--------------------------------------------------------
>>>>_______________________________________________
>>>>Insight-users mailing list
>>>>Insight-users at itk.org
>>>>http://www.itk.org/mailman/listinfo/insight-users
>>>
>>>
>>>
>>>--
>>>===========================================================
>>>Dr. Stephen R. Aylward
>>>Associate Professor of Radiology
>>>Adjunct Associate Professor of Computer Science and Surgery
>>>http://caddlab.rad.unc.edu aylward at unc.edu
>>>(919) 966-9695
>>>
>>>--------------------------------------------------------
>>>
>>>This email message is for the sole use of the intended recipient(s)
>>>and may contain confidential and privileged information.Any
>>>unauthorized review, use, disclosure or distribution is prohibited.
>>>If you are not the intended recipient, please contact the sender by
>>>reply email and destroy all copies of the original message. If you
>>>are the intended recipient, please be advised that the content of
>>>this message is subject to access, review and disclosure by the
>>>sender's Email System Administrator.
>>>--------------------------------------------------------
>>
>>
>
> --------------------------------------------------------
>
> This email message is for the sole use of the intended recipient(s)
and may contain confidential and privileged information.Any unauthorized
review, use, disclosure or distribution is prohibited. If you are not
the intended recipient, please contact the sender by reply email and
destroy all copies of the original message. If you are the intended
recipient, please be advised that the content of this message is subject
to access, review and disclosure by the sender's Email System
Administrator.
> --------------------------------------------------------
>
>
--
Dr. David A. Clunie mailto:dclunie at radpharm.com
Chief Technology Officer (RadPharm) http://www.radpharm.com/
Princeton Radiology Pharmaceutical Research Phone 609-936-2600
103 Carnegie Center Drive #300A Fax 609-936-2601
Princeton NJ 08540 http://www.dclunie.com/
--------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information.Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. If you are the intended recipient, please be advised that the content of this message is subject to access, review and disclosure by the sender's Email System Administrator.
--------------------------------------------------------
More information about the Insight-users
mailing list