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

[Mathieu Malaterre]

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...

Thanks,
-- 
Mathieu