<!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>&nbsp;</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.&nbsp; 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>&nbsp;</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>&gt; Hi Christoph, <BR>&gt; <BR>&gt; I had the 
  same problem and have already entered it in the bug tracker.<BR>&gt; <BR>&gt; 
  <A href="http://www.itk.org/Bug/bug.php?op=show&amp;bugid=3689&amp;pos=28" 
  eudora="autourl">http://www.itk.org/Bug/bug.php?op=show&amp;bugid=3689&amp;pos=28</A><BR>&gt; 
  <BR>&gt; A workaround it to set the ImageIO explicitly:<BR>&gt; <BR>&gt; 
  imageReader-&gt;SetImageIO( GiplImageIO::New() )<BR>&gt; <BR>&gt; but this is 
  of course not very convenient if you want to support<BR>&gt; multiple image 
  formats.<BR>&gt; <BR>&gt; Regards!<BR>&gt; Stefan<BR>&gt; <BR>&gt; At 12:40 
  17/01/07, Christoph Palm wrote:<BR>&gt; &gt; Hi there,<BR>&gt; &gt; <BR>&gt; 
  &gt; I work with gipl images and had troubles reading some<BR>&gt; &gt; of 
  them. After debugging it, it turns out to be a problem of the<BR>&gt; &gt; 
  ImageIOFactory, especially with the GDCM image reader. In fact, the<BR>&gt; 
  &gt; imageIOBase was by error assigned to GDCM instead of GIPL. Then, 
  of<BR>&gt; &gt; course, everything seriously went wrong and ended up with 
  false<BR>&gt; &gt; buffer<BR>&gt; &gt; allocations and a segmentation fault. 
  The wrong assignmed happend,<BR>&gt; &gt; because within the factory all 
  possible reader are tested to be the<BR>&gt; &gt; right one. The first one was 
  rejected, because the filename was not<BR>&gt; &gt; properly. Ok. The second 
  one was the GDCM reader, where no filename<BR>&gt; &gt; testing is applied. In 
  gdcmDocument.cxx, function CanReadFile<BR>&gt; &gt; the first Bytes are read 
  in as Uint16 and tested to be some numbers.<BR>&gt; &gt; If one of these 
  numbers are found, a dicom image without preample is<BR>&gt; &gt; assumed and 
  the function returns true.<BR>&gt; &gt; <BR>&gt; &gt; Unfortunately, by 
  coincidence obviously my gipl images showed one of<BR>&gt; &gt; these numbers, 
  namely 1,&nbsp; at the beginning of the file. In a gipl<BR>&gt; &gt; 
  image<BR>&gt; &gt; the header starts with UShort numbers for the dimensions. 
  My<BR>&gt; &gt; dimensions<BR>&gt; &gt; for the error case were 256 256 1 1 
  (since gipl images are always<BR>&gt; &gt; 4D).<BR>&gt; &gt; If I change the 
  dimensions to 255 256 1 1, for example, everything<BR>&gt; &gt; is<BR>&gt; 
  &gt; fine. Now my question: how to solve this in the Insight framework 
  in<BR>&gt; &gt; a<BR>&gt; &gt; clean way? I am not really familiar with DICOM 
  varieties. Is it<BR>&gt; &gt; possible<BR>&gt; &gt; to add a fileEnding test 
  to the GDCM reader? <BR>&gt; &gt; <BR>&gt; &gt; By the way, I also found a bug 
  in writing gipl images. This is<BR>&gt; &gt; already<BR>&gt; &gt; putted into 
  the BugTracker. Is it possible, that I am the one and<BR>&gt; &gt; 
  only<BR>&gt; &gt; here who is working with GIPL images? ;-)<BR>&gt; &gt; 
  <BR>&gt; &gt; Regards<BR>&gt; &gt; <BR>&gt; &gt; Christoph<BR>&gt; &gt; 
  <BR>&gt; &gt; </FONT></BLOCKQUOTE><BR></BODY></HTML>