<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.2963" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=777541620-17012007><FONT face=Arial
color=#0000ff size=2>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.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=777541620-17012007><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=777541620-17012007><FONT face=Arial
color=#0000ff size=2>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.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=777541620-17012007><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=777541620-17012007><FONT face=Arial
color=#0000ff size=2>Jim</FONT></SPAN></DIV><BR>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B>
insight-users-bounces+millerjv=crd.ge.com@itk.org
[mailto:insight-users-bounces+millerjv=crd.ge.com@itk.org] <B>On Behalf Of
</B>Stefan Klein<BR><B>Sent:</B> Wednesday, January 17, 2007 9:32
AM<BR><B>To:</B> Christoph Palm<BR><B>Cc:</B>
insight-users@itk.org<BR><B>Subject:</B> Re: [Insight-users] ImageIOFactory
problem<BR></FONT><BR></DIV>
<DIV></DIV><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 class=cite cite="" type="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><BR></BODY></HTML>