[Insight-users] ImageIOFactory problem

[Christoph Palm]

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