[Insight-developers] GDCM bug interpreting PixelSpacing

[Williams, Norman K]

I wrote a small test program to show this problem.  You are correct that
GDCM isn't reporting the spacing correctly -- it comes out 1,1,1

There's a function called ImageHelper::GetSpacingTagFromMediaStorage,
which looks at the Media Storage type of an image, and decides what DICOM
tag to look at to find spacing.  This function says to use 0028,0034 --
which doesn't exist in the DICOM files in that sample dataset.

Those files do, however, have 0028,0030 (PixelSpacing), which is what
DCMTK uses. if you happen to look at
ITK/Modules/IO/DCMTK/src/itkDCMTKFileReader.cxx,
itk::DCMTKFileReader::GetSpacing() tries a bunch of different DICOM tags,
in order of most commonly encountered to least commonly encountered.  It
doesn't try to use different tags based on different Media Storage Types.

If you look at gdcmImageHelper.cxx, it's pretty clear that the authors
were pretty clear about what tag to use in most cases.  In the case of
Ultrasound, they use 0028,0030 and there's a comment that says FIXME.

I can fix the GDCMImageIO such that it does a bit of fiddling to determine
if GDCMImageHelper is getting spacing wrong.

I keep thinking GDCM is a dead issue; that anything using it now is legacy
code, and any new development will depend on DCMTK. DCMTK which has a much
larger user base and more commitment to ongoing development than GDCM.

I never have to look at the DCMTK source code to figure out what's wrong
-- if there's something wrong it's my fault.  With GDCM I always have to
go spelunking in the code to figure out why it's letting me down.

--
Kent Williams norman-k-williams at uiowa.edu






On 6/18/13 2:31 PM, "Andriy Fedorov" <fedorov at bwh.harvard.edu> wrote:

>Kent,
>
>I have this dataset which is not loaded correctly by ITK/GDCM. The
>spacing should be 0.174x0.178 (approximately, see exact values in
>PixelSpacing tag; also note the in-slice spacing is anisotropic),
>however, if I read it (either single slice or the whole volume) using
>ITK+GDCM, the in-slice spacing is set to 1x1. It is read correctly
>when ITK is compiled with DCMTK.
>
>Hans and I looked into this, and we confirmed these issues, and what
>seems to be a bug in GDCM. This could be due to modality-specific
>handling of the data (the modality is US here).
>
>Hans told me you can look into this in GDCM, could you please?
>
>Here's the dataset:
>https://www.dropbox.com/s/d7oteqzi0j0bsrx/gdcm_issue.tgz
>
>Please let me know if you need any extra information, and how it is going!
>
>--
>Andriy Fedorov, Ph.D.
>
>Brigham and Women's Hospital
>Harvard Medical School
>75 Francis Street
>Boston, MA 02115 USA
>fedorov at bwh.harvard.edu
>(617) 525-6258 (office)
>(757) 561-0110 (mobile)



________________________________
Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged.  If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited.  Please reply to the sender that you have received the message in error, then delete it.  Thank you.
________________________________