[Insight-users] GDCM crashes when reading some dicom images

[Mathieu Malaterre]

On Fri, Apr 25, 2008 at 3:36 PM, Jesús Spí­nola <jspinola at gmail.com> wrote:
>
>
>
>
> On Fri, Apr 25, 2008 at 3:19 PM, Mathieu Malaterre
> <mathieu.malaterre at gmail.com> wrote:
> >
> >
> >
> > On Fri, Apr 25, 2008 at 3:01 PM, Jesús Spí­nola <jspinola at gmail.com>
> wrote:
> > >
> > >
> > >
> > >
> > > On Fri, Apr 25, 2008 at 2:28 PM, Mathieu Malaterre
> > > <mathieu.malaterre at gmail.com> wrote:
> > > > Hi Jesús,
> > > >
> > > >
> > > >
> > > >
> > > > On Fri, Apr 25, 2008 at 2:15 PM, Jesús Spí­nola <jspinola at gmail.com>
> > > wrote:
> > > > >
> > > > >
> > > > >
> > > > > On Fri, Apr 25, 2008 at 12:24 PM, Mathieu Malaterre
> > > > > <mathieu.malaterre at gmail.com> wrote:
> > > > > > Hi Jesús,
> > > > > >
> > > > > > The short answer:
> > > > > >  Indeed this is a bug in the code. This is fixed in the current
> ITK
> > > CVS:
> > > > > >
> > > > > > $ cvs ci -m"ENH: When gdcm cannot read, it means gdcm cannot
> read..."
> > > > > > itkGDCMImageIO.cxx
> > > > > > /cvsroot/Insight/Insight/Code/IO/itkGDCMImageIO.cxx,v  <--
> > > > > itkGDCMImageIO.cxx
> > > > > > new revision: 1.136; previous revision: 1.135
> > > > > >
> > > > > > $ cvs ci -m"ENH: prevent segfault. The last else should not always
> > > > > > call the jpeg decompressor when the image is NOT jpeg"
> > > > > >
> > > /cvsroot/Insight/Insight/Utilities/gdcm/src/gdcmJPEGFragmentsInfo.cxx,v
> > > > > >  <--  src/gdcmJPEGFragmentsInfo.cxx
> > > > > > new revision: 1.6; previous revision: 1.5
> > > > > >
> /cvsroot/Insight/Insight/Utilities/gdcm/src/gdcmPixelReadConvert.cxx,v
> > > > > >  <--  src/gdcmPixelReadConvert.cxx
> > > > > > new revision: 1.9; previous revision: 1.8
> > > > > >
> > > > >
> > > > > So, if apply this changes it would prevent the application to crash,
> but
> > > it
> > > > > would not be able to open the images. Is that right?
> > > > >
> > > > >
> > > > > >
> > > > > > The long answer:
> > > > > >
> > > > > > I have had a look at your image, and those are the famous ELSCINT1
> /
> > > > > > PMSCT_RLE1 compressed image. They are falsely declared as MR Image
> > > > > > Storage (1.2.840.10008.5.1.4.1.1.4), they contains all information
> but
> > > > > > are missing the most important one: Pixel Data (7fe0,0010).
> Instead it
> > > > > > is being replaced with a binary blob at Private Data Element
> > > > > > (07a1,xx0a,ELSCINT1), with an unknown compression algorithm.
> > > > > > This issue has very recently been raised in the
> comp.protocols.dicom,
> > > > > >
> > > > > >
> > > > >
> > >
> http://groups.google.com/group/comp.protocols.dicom/browse_thread/thread/f07b8ffda372f4f7
> > > > > >
> > > > > > As of now, I do not know of any library that can read your image
> > > > > > (please get in touch with Yves Martel, CC in this email, if you
> want
> > > > > > more info). But again there is no guarantee that this image will
> ever
> > > > > > be read by something else than the original Scanner. As a side
> note,
> > > > > > you should rather contact your PACS admin, and ask him to properly
> > > > > > export those images (instead of directly ftp'ing into the
> machine).
> > > > > >
> > > > >
> > > > > Thanks a lot for this information. I'm in touch with the PACS admin
> to
> > > solve
> > > > > this problem. I hope he could solve this problem making the
> appropriatte
> > > > > export to standard DICOM.
> > > > >
> > > > >
> > > > > >
> > > > > > HTH
> > > > > > -Mathieu
> > > > > > Ps: so when you say vtk is able to open the image, you mean it
> does
> > > > > > not crash ? I would be *very* surprised if vtkDICOMImageReader
> would
> > > > > > be able to read, say your image: study1/s10/i10 :)
> > > > >
> > > > > You're right, It does not crash with vtk, but i didn't tried to view
> the
> > > > > image. I miss to tell that detail.
> > > > > But dcmtk is able to open it correctly, because I create the preview
> > > > > thubmnails with dcmtk, so with dcmtk I can render the image.
> > > >
> > > > Would you be kind enough and tell me how you are generating this
> > > > thumbnail ? The only -believable- option I can think of is that you
> > > > are running your program on the original image (pre anonymization) and
> > > > they still contain the Icon Image Sequence (a small screenshot
> > > > generally 64x64) that is *not* compressed and is perfectly readable by
> > > > all reader. But -again- this is NOT the Pixel Data, and Icon Image
> > > > Sequence is absolutely not passed to ITK.
> > > >
> > >
> > > I generate the thumbnail based on this code:
> > > http://forum.dcmtk.org/viewtopic.php?t=120&highlight=pixmap
> > >
> > > I've made a dicom dump of the original image and surprisingly it
> contains
> > > the Pixel Data (7fe0,0010)! Maybe the ELSCINT1 compression is made by
> the
> > > philips sofware when anonymazing the images.
> > >
> > > So, beacause the anonymization by philips is introducing some errors
> that
> > > impede to check the real problem, I've attached an anonymized image by
> hand
> > > ( with dcmtk's dcmmodify ). That's the first image of the first series.
> > >
> > > I hope we can find the real problem
> >
> > LOL !
> >
> > This is the best anonymization software I have ever seen, they really
> > hide *all* patient information :)
> >
> > Thanks for the file, I'll check why gdcm 1.2 is reporting it as
> > non-readable, but gdcm 1.3 can read it fine...
> >
>
> Does the latest version of itk (3.6.0) comes with gdcm 1.2 or 1.3? Updating
> to the latest version of itk solves the problem or may I have to apply some
> patch?
> thanks for your help!

Well it does not crash anymore :)
But your image still cannot be read. There is an issue in gdcm 1.2
when the Image Location (an old ACR tag) is encoded with VR=UN. We'll
try to fix gdcm 1.2 ASAP.

I'll let you know when this is merge in GDCM-ITK.

Thanks again for your time, and data to track down this nasty bug.
-- 
Mathieu