[Insight-users] Slice spacing of DICOM series
Elena Pavlovskaia
Elena.Pavlovskaia at otismed.com
Mon Nov 10 16:44:44 EST 2008
Hi,
In insight-users archive I found an advice
on what value to use for the slice spacing in case
if the field Spacing Between Slices (0018,0088)
contains a different value than the value computed from
Image Position (0020,0032) of two parallel slices along
the normal to Image Orientation (0020,0037), see below.
The advice is to always use the latter as it is a known
bug for some scanners to have a wrong value in (0018,0088).
After processing thousands of DICOM series with consistent
spacing values we started getting data from new MRI centers
with those values different by 1 - 2%.
The advice was given in 2005. I wonder if there might be new
information since then:
Is there a chance that some scanners have a different bug,
so that they give the first value (0018,0088) correctly,
but the computed value from (0020,0032) and (0020,0037)
would be incorrect?
Thanks,
Elena
---------------------------------------
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
>>>>>>
>>>>>>--------------------------------------------------------
>>>>>>
CONFIDENTIAL COMMUNICATION: This email (and accompanying
documents) transmitted is intended only for the person or entity
to which it is addressed and may contain confidential and/or
privileged material. Any review, retransmission, dissemination or
other use of, or taking of any action in reliance upon, this
information by persons or entities other than the intended
recipient is prohibited, and may be a violation of law. If you
believe that you received this e-mail in error, please do not
read this e-mail or any attached items. Please delete the e-mail
and all attachments, including any copies thereof, and inform the
sender that you have deleted the e-mail, all attachments and any
copies thereof.
PRIVACY/CONFIDENTIALITY NOTICE REGARDING PROTECTED HEALTH
INFORMATION: This email (and accompanying documents) may contain
protected health information that is privileged, confidential
and/or otherwise exempt from and protected from disclosure under
applicable laws, including the Health Insurance Portability and
Accountability Act. The information contained in this email (and
any accompanying documents) is intended only for the personal and
the confidential use of the intended recipient. If the reader of
this message is not the intended recipient or the employee or
agent responsible for delivering it to the intended recipient,
you are hereby notified that you have received this information
in error and that any review, dissemination, distribution,
copying or action taken in reliance on the contents of this
communication is strictly prohibited. If you have received this
communication in error, please destroy it immediately and notify
the sender.
More information about the Insight-users
mailing list