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

[Jesús Spí­nola]

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!


> Thanks,
> --
> Mathieu
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-users/attachments/20080425/8a5cf569/attachment.htm>