[Insight-users] Slice spacing of DICOM series
Mathieu Malaterre
mathieu.malaterre at gmail.com
Tue Nov 11 07:00:08 EST 2008
Hi Elena,
Short answer: No ! Image Position (Patient) and Image Orientation
(Patient) are the only way to compute the Spacing Between Slices in a
robust way. I do not know if 1-2% should be considered large or not.
Anyway what I would do is:
1. Check you are not missing any slice. There is a code path, that
will allow people to load a DICOM Series with a missing slice, and
will not produce any kind of warning. That could explain the incorrect
computation of the spacing using IPP & IOP.
2. I am pretty sure this cannot be the case, but computation is being
done using single precision floating point value. Are your IPP / IOP
values very small (~1e-6) ? How about the Slice Spacing ?
3. Is Spacing Between Slices *completely* consistant thoughout the
series. By 'completely' I mean that you can compare the ASCII string
used to stored the floating point value. There is a subtle difference
in between a per slice definition of Slice Spacing and a general
(homogenous) Slice Spacing for the complete Series.
4. All the IOPs for your series are clearly identical ? (again ASCII
string for IOP should be identical).
Let us know what you find out
-Mathieu
On Mon, Nov 10, 2008 at 10:44 PM, Elena Pavlovskaia
<Elena.Pavlovskaia at otismed.com> wrote:
> 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.
>
> _______________________________________________
> Insight-users mailing list
> Insight-users at itk.org
> http://www.itk.org/mailman/listinfo/insight-users
>
--
Mathieu
More information about the Insight-users
mailing list