[Insight-users] ImageIOFactory problem

[Stefan Klein]

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/39638b7f/attachment.html