[Insight-users] ImageIOFactory problem

[Miller, James V (GE, Research)]

Early DICOM files were missing a magic number (in current DICOM, each
image has the magic number DICM at a prescribed offset). The GDCM
library tries to guess whether a file is missing its magic number by
looking for other recognizable DICOM tags. The GDCM library is mistaking
your GIPL content as a valid DICOM tag.
 
Maybe Mattieu can modify the gdcm::Document::CanReadFile() method so
that this test checks more of the file to determine if it is a valid
DICOM file.  Or maybe ITK should only process modern DICOM files that
have the DICM magic number.
 
Jim

________________________________

From: insight-users-bounces+millerjv=crd.ge.com at itk.org
[mailto:insight-users-bounces+millerjv=crd.ge.com at itk.org] On Behalf Of
Stefan Klein
Sent: Wednesday, January 17, 2007 9:32 AM
To: Christoph Palm
Cc: insight-users at itk.org
Subject: Re: [Insight-users] ImageIOFactory problem


Hi Christoph:

the order is defined in the following file:

itkImageIOFactory.cxx

Regards!
Stefan.

At 14:27 17/01/07, Christoph Palm wrote:


	Hi Stefan,
	
	knowing this would have saved me at least one busy day :-(
	But thanks for pointing this out, I have now voted for the
	bug to give it a push after more than one year.
	
	But anyway, it could be a solution to throw the GDCM imageIO
	at the end of the possible imageIO list. Only if all other
formats
	are excluded, then the test on a Dicom image would be performed.
	Do you know by heart, where the sorting of this list is
determined?
	
	Regards
	
	Christoph
	
	On Wed, 2007-01-17 at 14:08 +0100, Stefan Klein wrote:
	> Hi Christoph, 
	> 
	> I had the same problem and have already entered it in the bug
tracker.
	> 
	> http://www.itk.org/Bug/bug.php?op=show&bugid=3689&pos=28
	> 
	> A workaround it to set the ImageIO explicitly:
	> 
	> imageReader->SetImageIO( GiplImageIO::New() )
	> 
	> but this is of course not very convenient if you want to
support
	> multiple image formats.
	> 
	> Regards!
	> Stefan
	> 
	> At 12:40 17/01/07, Christoph Palm wrote:
	> > Hi there,
	> > 
	> > I work with gipl images and had troubles reading some
	> > of them. After debugging it, it turns out to be a problem of
the
	> > ImageIOFactory, especially with the GDCM image reader. In
fact, the
	> > imageIOBase was by error assigned to GDCM instead of GIPL.
Then, of
	> > course, everything seriously went wrong and ended up with
false
	> > buffer
	> > allocations and a segmentation fault. The wrong assignmed
happend,
	> > because within the factory all possible reader are tested to
be the
	> > right one. The first one was rejected, because the filename
was not
	> > properly. Ok. The second one was the GDCM reader, where no
filename
	> > testing is applied. In gdcmDocument.cxx, function
CanReadFile
	> > the first Bytes are read in as Uint16 and tested to be some
numbers.
	> > If one of these numbers are found, a dicom image without
preample is
	> > assumed and the function returns true.
	> > 
	> > Unfortunately, by coincidence obviously my gipl images
showed one of
	> > these numbers, namely 1,  at the beginning of the file. In a
gipl
	> > image
	> > the header starts with UShort numbers for the dimensions. My
	> > dimensions
	> > for the error case were 256 256 1 1 (since gipl images are
always
	> > 4D).
	> > If I change the dimensions to 255 256 1 1, for example,
everything
	> > is
	> > fine. Now my question: how to solve this in the Insight
framework in
	> > a
	> > clean way? I am not really familiar with DICOM varieties. Is
it
	> > possible
	> > to add a fileEnding test to the GDCM reader? 
	> > 
	> > By the way, I also found a bug in writing gipl images. This
is
	> > already
	> > putted into the BugTracker. Is it possible, that I am the
one and
	> > only
	> > here who is working with GIPL images? ;-)
	> > 
	> > Regards
	> > 
	> > Christoph
	> > 
	> > 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://public.kitware.com/pipermail/insight-users/attachments/20070117/d68811aa/attachment.html