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

[Mathieu Malaterre]

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.

Please check that your original images have a Data Element
(0088,0200). There you'll find a small Pixel Data element: (7fe0,0010)
which is the thumbnail you might be seeing.

I have CC the dcmtk team, that -I am sure- will confirm your image
simply cannot be read with there software.

Regards,
-- 
Mathieu