[Insight-users] ImageIOFactory problem

[Christoph Palm]

It's ok for me. But changing the order of the imageIOs in the
Factory to ensure, that GDCM is the last one, is working also
very well.

Christoph

On Wed, 2007-01-17 at 15:35 -0500, Mathieu Malaterre wrote:
> I like that ! It's very simple and should be robust most of the time.
> So in summary the ImageIOFactory will automagically recognize your DICOM 
> file if/only if:
> 
> 1. It has the .dcm/.DCM extension
> and/or
> 2. It contains the DICM keyword as DICOM Part 10 recommend.
> 
> Any other case should be handle by explicitly setting the DICOM factory 
> manually.
> 
> This is at least backward compatible with ITK testing data:
> 
> 1. Contains DICM AND filenames contains .dcm
> DicomSeries/Image0075.dcm
> DicomSeries/Image0076.dcm
> DicomSeries/Image0077.dcm
> 
> 2. filename contains .dcm (but no DICM)
> dicom-sc_cs-1.dcm
> 
> 3. Contains DICM (but no extension .dcm)
> 012345.002.050
> 
> Comments ?
> Mathieu
> 
> 
> Miller, James V (GE, Research) wrote:
> > 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 
> >> <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
> >> > >
> >> > > 
> > 
> 
-- 
----