[Insight-users] ImageIOFactory problem

[Mathieu Malaterre]

Fixed in ITK CVS.

$ cvs ci -m"ENH: By default only recognize files that either have the 
.DCM/dcm extension OR that contains the DICM magic number. Very old 
ACRNEMA files might not be recognized anymore. In which case user will 
either have to rename the file to the proper extension, or instanciate 
explicitely the GDCMImageIO." itkGDCMImageIO.cxx itkImageIOFactory.cxx
/cvsroot/Insight/Insight/Code/IO/itkGDCMImageIO.cxx,v  <-- 
itkGDCMImageIO.cxx
new revision: 1.118; previous revision: 1.117
/cvsroot/Insight/Insight/Code/IO/itkImageIOFactory.cxx,v  <-- 
itkImageIOFactory.cxx
new revision: 1.32; previous revision: 1.31

-M

Mathieu Malaterre wrote:
> I like that ! It's very simple and should be robust most of the time.
> So in summary the ImageIOFactory will automagically recognize your DICOM 
> file if/only if:
> 
> 1. It has the .dcm/.DCM extension
> and/or
> 2. It contains the DICM keyword as DICOM Part 10 recommend.
> 
> Any other case should be handle by explicitly setting the DICOM factory 
> manually.
> 
> This is at least backward compatible with ITK testing data:
> 
> 1. Contains DICM AND filenames contains .dcm
> DicomSeries/Image0075.dcm
> DicomSeries/Image0076.dcm
> DicomSeries/Image0077.dcm
> 
> 2. filename contains .dcm (but no DICM)
> dicom-sc_cs-1.dcm
> 
> 3. Contains DICM (but no extension .dcm)
> 012345.002.050
> 
> Comments ?
> Mathieu
> 
> 
> Miller, James V (GE, Research) wrote:
>> 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.
>>  
>> 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.
>>  
>> Jim
>>
>> ------------------------------------------------------------------------
>> *From:* insight-users-bounces+millerjv=crd.ge.com at itk.org 
>> [mailto:insight-users-bounces+millerjv=crd.ge.com at itk.org] *On Behalf 
>> Of *Stefan Klein
>> *Sent:* Wednesday, January 17, 2007 9:32 AM
>> *To:* Christoph Palm
>> *Cc:* insight-users at itk.org
>> *Subject:* Re: [Insight-users] ImageIOFactory problem
>>
>> 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 
>>> <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
>>> > >
>>> > > 
>>
> 
>