[Insight-users] Slice spacing of DICOM series
Elena Pavlovskaia
Elena.Pavlovskaia at otismed.com
Tue Nov 11 20:55:41 EST 2008
Hi Mathieu,
Thank you very much for your answer.
We are very much concerned with the precision of our data because
we are using it in a clinical application. In order to capture
any possible error we introduced multiple procedures for verification
of data consistency. In particular, we verify that we get the same
value for inter slice spacing between EVERY pair of slices
if we compute it using IPP & IOP or if we read it in (0018,0088) field.
As you pointed out sometimes we get missing slices or extra slices.
Our verification algorithm captures both cases.
Yet now we see a new type of data inconsistency. The spacing computed
with IPP & IOP is 2.049 mm and is pretty consistent for every pair of
slices (variations under 0.1%), yet (0018,0088) is always 1.999999762.
> Are your IPP / IOP values very small (~1e-6) ?
> How about the Slice Spacing ?
The IPP values are within 0 - 200 mm interval. The IOP values are
-0.194472\0.9809080958\0\0.1169777811\0.02319164202\-0.9928637147.
Per my estimation I might get under 0.005 mm error due to single
precision floating point arithmetic with my numbers. Yet I am getting
10 times higher error.
> Is Spacing Between Slices *completely* consistent ... ?
Yes.
> All the IOPs for your series are clearly identical ?
No! But the variations are under floating point precision, for example:
-0.194472\0.9809080958\0\0.1169777811\0.02319164202\-0.9928637147.
-0.194472\0.9809080958\0\0.116977796\0.02319164388\-0.9928637147.
This and other trouble data comes from CT scanner
GE Medical Systems, LightSpeed Pro 16.
We mostly work with MRI data. When we get CT data, they reformat it
for us to match our MRI spacing requirements (2 mm spacing between
the slices). The problem data was also reformatted.
I wonder if it is safe to assume that the value computed with
IPP & IOP is still reliable even with CT and with reformatting?
Thank you very much!
Elena
-----Original Message-----
From: Mathieu Malaterre [mailto:mathieu.malaterre at gmail.com]
Sent: Tuesday, November 11, 2008 4:00 AM
To: Elena Pavlovskaia
Cc: insight-users at itk.org
Subject: Re: [Insight-users] Slice spacing of DICOM series
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