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