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

[Mathieu Malaterre]

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

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

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 :)


On Thu, Apr 24, 2008 at 10:10 PM, Jesús Spí­nola <jspinola at gmail.com> wrote:
> Hello,
>
> I'm using itk 2.8.1 and I have a problem reading some DICOM images with
> itkGDCMImageIO. For most of images I opened since now, it works ok, but I
> have images from several studies that is not able to open because it crashes
> with a SIGFPE (floating point exception). When debugging, this is the
> message after crashing
>
> Program received signal SIGFPE, Arithmetic exception.
> [Switching to Thread -1223084336 (LWP 6551)]
>  0xb7de14e6 in gdcm::PixelReadConvert::ConvertReArrangeBits () from
> /usr/lib/InsightToolkit/libitkgdcm.so.2.8
>
>
> and the backtrace is the following:
>
>
>  #0  0xb7de14e6 in gdcm::PixelReadConvert::ConvertReArrangeBits () from
> /usr/lib/InsightToolkit/libitkgdcm.so.2.8
> #1  0xb7de9c31 in gdcm::PixelReadConvert::ReadAndDecompressPixelData () from
> /usr/lib/InsightToolkit/libitkgdcm.so.2.8
>  #2  0xb7dbd69c in gdcm::FileHelper::GetRaw () from
> /usr/lib/InsightToolkit/libitkgdcm.so.2.8
> #3  0xb7dbebf2 in gdcm::FileHelper::GetImageData () from
> /usr/lib/InsightToolkit/libitkgdcm.so.2.8
>  #4  0xb7ee1892 in itk::GDCMImageIO::Read () from
> /usr/lib/InsightToolkit/libITKIO.so.2.8
> #5  0x08061964 in itk::ImageFileReader<itk::Image<int, 3u>,
> itk::DefaultConvertPixelTraits<int> >::GenerateData ()
>  #6  0xb7a62380 in itk::ProcessObject::UpdateOutputData () from
> /usr/lib/InsightToolkit/libITKCommon.so.2.8
> #7  0xb7a1f969 in itk::DataObject::UpdateOutputData () from
> /usr/lib/InsightToolkit/libITKCommon.so.2.8
>  #8  0xb7a1f770 in itk::DataObject::Update () from
> /usr/lib/InsightToolkit/libITKCommon.so.2.8
> #9  0xb7a5ffca in itk::ProcessObject::UpdateLargestPossibleRegion () from
> /usr/lib/InsightToolkit/libITKCommon.so.2.8
>  #10 0x0805d6c0 in itk::ImageSeriesReader<itk::Image<int, 3u>
> >::GenerateData ()
> #11 0xb7a62380 in itk::ProcessObject::UpdateOutputData () from
> /usr/lib/InsightToolkit/libITKCommon.so.2.8
>  #12 0xb7a1f969 in itk::DataObject::UpdateOutputData () from
> /usr/lib/InsightToolkit/libITKCommon.so.2.8
> #13 0xb7a1f770 in itk::DataObject::Update () from
> /usr/lib/InsightToolkit/libITKCommon.so.2.8
>  #14 0xb7a60062 in itk::ProcessObject::Update () from
> /usr/lib/InsightToolkit/libITKCommon.so.2.8
> #15 0x0804e0f4 in main ()
>
> To test this problem I've writen a little program I've attached
> (gdcmBug.cpp) reproducing the problem. You can use the following anonymized
> study ( http://hades.udg.edu/~chus/study1.tar.gz ) with some series to test
> this bug. It crashes with any of the images of the study.
>
> I also tried to read the same images with other libraries such as vtk or
> dcmtk and they're able to open the same images successfully.
>
> Assuming ITKINCLUDEDIR is /usr/include/InsightToolkit and ITKLIBDIR is
> /usr/lib/InsightToolkit, the compile command for g++ is the following
>
>  g++ -o gdcmBug gdcmBug.o -I. -I/usr/include/InsightToolkit
> -I/usr/include/InsightToolkit/IO -I/usr/include/InsightToolkit/gdcm/src
> -L/usr/lib/InsightToolkit -lITKIO -litkgdcm
>
> To run this test you have to pass by argument the files you want to read.
>
> For example, if you want to read 3 images (im1, im2, im3) from the same
> series:
>
> $>gdcmBug im1 im2 im3
>
> If you want to test with only one single image
>
> $>gdcmbug im1
>
> and so on...
>
> I tested this under Linux Mandriva 2008.0 and Kubuntu Feisty 7.04.
>
> Maybe this bug is resolved in a more recent version of itk, but I don't know
> it. If so, let me know which version has solved this problem.
>
> I hope this test and the images I provided can help to find the problem. I
> have more images to reproduce the problem, if necessary.
>
>
> Thanks in advance!
>
> _______________________________________________
>  Insight-users mailing list
>  Insight-users at itk.org
>  http://www.itk.org/mailman/listinfo/insight-users
>
>



-- 
Mathieu