[Insight-users] [Gdcm2] Reading DICOM spacing

Mario Ceresa mrceresa at gmail.com
Mon Apr 26 06:48:37 EDT 2010


Thanks Jean-Pierre you are right.

I read the original images from the directory and ITK (which uses
gdcm) gives the correct values for the spacing:

In [4]: img.GetSpacing()
Out[4]: itkVectorD3([0.808594, 0.808594, 5])

The image I sent was the first step of a long processing algorithm and
I wasn't aware that I should have changed the dicom tag manually to
reflect the change.

So probably it is not a *legal* image and gdcm has all the rights to
misbehave. Still a warning somewhere would have been helpful :)

Is there any way to get familiarized with those subtle aspects of the
dicom standard without reading the full specification?

Do you know of any "dicom image validator" to check for similar
problem in the future? I found the one from offis:

http://dicom.offis.de/dcmcheck.php.en

but there is no source code nor binary available.

With best regards,


Mario

On 26 April 2010 10:51, Jean-Pierre Roux <jpr at creatis.insa-lyon.fr> wrote:
> Hi,
>
> The image has a [Media Storage SOP Class UID] equals to [CT Image Storage]
> *and* is a multiframe image (it shouln't be : a *legal* Dicom CT
> multiframe shoud be 'Enhance CT Image Storage')
>
> The old gdcm1.3 was not aware of this feature, and gives accurate result
> for Z Spacing.
> :-(
>
> gdcm2 is follows *much more* Dicom norm, and don't try to apply any
> (stupid) heuristics -that would give an accurate result in this case-,
> like gdcm1.3 does.
>
>
> Mathieu, any idea?
>
> Jean-Pierre Roux
>
>
>
> is a On 04/26/2010 10:20 AM, Mario Ceresa wrote:
>> Thanks Mathieu, for your answer.
>> Please forgive if I go on with this issue but it is very important to me.
>>
>> I tried reading the link:
>>
>> http://sourceforge.net/apps/mediawiki/gdcm/index.php?title=Imager_Pixel_Spacing
>>
>> but I find extremely difficult to understand as it is organized more
>> like a dumped chat than as an organic test (no intention to flame!)
>>
>> I uploaded one of the images that was giving me problem:
>>
>> http://www.fileconvoy.com/Retrieve.php?id=94ab11889264e
>>
>> This is the entire serie written in a single image with ITK.
>>
>> gdcminfo gives the following output:
>>
>> $ gdcminfo spacing_test.dcm
>> MediaStorage is 1.2.840.10008.5.1.4.1.1.2 [CT Image Storage]
>> TransferSyntax is 1.2.840.10008.1.2 [Implicit VR Little Endian:
>> Default Transfer Syntax for DICOM]
>> NumberOfDimensions: 3
>> Dimensions: (512,512,61)
>> Origin: (-190.629,-333.629,-62)
>> Spacing: (0.742188,0.742188,1)
>> DirectionCosines: (1,0,0,0,1,0)
>> Rescale Intercept/Slope: (0,1)
>> SamplesPerPixel    :1
>> BitsAllocated      :16
>> BitsStored         :16
>> HighBit            :15
>> PixelRepresentation:1
>> ScalarType found   :INT16
>> PhotometricInterpretation: MONOCHROME2
>> PlanarConfiguration: 0
>> TransferSyntax: 1.2.840.10008.1.2
>> Orientation Label: AXIAL
>>
>> Here you can see that z-spacing is 1 even if the "number of dim" is 3.
>>
>> And Slice Thickness is 5:
>>
>> $ gdcmdump spacing_test.dcm | grep Slice
>> (0018,0050) ?? (DS) [5 ]                                          #
>> 2,1 Slice Thickness
>>
>> Could you help me in selecting the correct value to compute the
>> volume? Maybe the zspacing is correctly computed and I'm fooled by the
>> fact that it is also the default value in case of error and that the
>> slice thickness is so much higher.
>>
>> Thanks for your continued support,
>>
>> With best regards
>>
>> Mario
>>
>>
>> On 24 April 2010 23:53, Mathieu Malaterre<mathieu.malaterre at gmail.com>  wrote:
>>
>>> On Tue, Apr 20, 2010 at 2:07 PM, Mario Ceresa<mrceresa at gmail.com>  wrote:
>>>
>>>> Hello everybody!
>>>> I have a small problem in understanding how to read DICOM spacing:
>>>>
>>>> With gdcmdump I see that my image has:
>>>> (0028,0030) [0.7421875\0.7421875 ]               # 20,2 Pixel Spacing
>>>> and
>>>> (0018,0050) [5 ]                                 # 2,1 Slice Thickness
>>>>
>>> Slice Thickness is NOT Spacing Between Slices. Those two values are
>>> totally uncorrelated. Please check links from José, this will also
>>> teach you about DICOM Objects. For instance for RT Object or Enhanced
>>> object the Spacing should be read at different places than in CT or MR
>>> Image.
>>>
>>> This is FAQ #2:
>>>
>>> Where is the value of gdcm.Image.Spacing coming from ?
>>> http://sourceforge.net/apps/mediawiki/gdcm/index.php?title=Using_GDCM_API#Where_is_the_value_of_gdcm.Image.Spacing_coming_from_.3F
>>>
>>>
>>>> but still gdcminfo prints:
>>>> Spacing: (0.742188,0.742188, 1)
>>>> instead of:
>>>> Spacing: (0.742188,0.742188, 5)
>>>>
>>> 1 is indeed a 'best' guess since you only provide a single Slice.
>>>
>>> --
>>> Mathieu
>>>
>>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Gdcm-developers mailing list
>> Gdcm-developers at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/gdcm-developers
>>
>>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Gdcm-developers mailing list
> Gdcm-developers at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gdcm-developers
>


More information about the Insight-users mailing list