ImageIOFactory problem

[Christoph Palm]

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

[Stefan Klein]

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

Post by Christoph Palm
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
_______________________________________________
Insight-users mailing list
http://www.itk.org/mailman/listinfo/insight-users

[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

Post by Stefan Klein
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
imageReader->SetImageIO( GiplImageIO::New() )
but this is of course not very convenient if you want to support
multiple image formats.
Regards!
Stefan

Post by Christoph Palm
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

[Stefan Klein]

Hi Christoph:

the order is defined in the following file:

itkImageIOFactory.cxx

Regards!
Stefan.

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

Post by Stefan Klein
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
imageReader->SetImageIO( GiplImageIO::New() )
but this is of course not very convenient if you want to support
multiple image formats.
Regards!
Stefan

Post by Christoph Palm
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

[Mathieu Malaterre]

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

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
------------------------------------------------------------------------
*Stefan Klein
*Sent:* Wednesday, January 17, 2007 9:32 AM
*To:* Christoph Palm
*Subject:* Re: [Insight-users] ImageIOFactory problem
itkImageIOFactory.cxx
Regards!
Stefan.

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

Post by Stefan Klein
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>

Post by Stefan Klein
imageReader->SetImageIO( GiplImageIO::New() )
but this is of course not very convenient if you want to support
multiple image formats.
Regards!
Stefan

Post by Christoph Palm
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

[Christoph Palm]

It's ok for me. But changing the order of the imageIOs in the
Factory to ensure, that GDCM is the last one, is working also
very well.

Christoph

Post by Mathieu Malaterre
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
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.
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

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
------------------------------------------------------------------------
*Stefan Klein
*Sent:* Wednesday, January 17, 2007 9:32 AM
*To:* Christoph Palm
*Subject:* Re: [Insight-users] ImageIOFactory problem
itkImageIOFactory.cxx
Regards!
Stefan.

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

Post by Stefan Klein
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>

Post by Stefan Klein
imageReader->SetImageIO( GiplImageIO::New() )
but this is of course not very convenient if you want to support
multiple image formats.
Regards!
Stefan

Post by Christoph Palm
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

[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

Post by Mathieu Malaterre
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
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.
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

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
------------------------------------------------------------------------
Of *Stefan Klein
*Sent:* Wednesday, January 17, 2007 9:32 AM
*To:* Christoph Palm
*Subject:* Re: [Insight-users] ImageIOFactory problem
itkImageIOFactory.cxx
Regards!
Stefan.

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

Post by Stefan Klein
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>

Post by Stefan Klein
imageReader->SetImageIO( GiplImageIO::New() )
but this is of course not very convenient if you want to support
multiple image formats.
Regards!
Stefan

Post by Christoph Palm
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

[Miller, James V (GE, Research)]

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-***@public.gmane.org
[mailto:insight-users-bounces+millerjv=crd.ge.com-***@public.gmane.org] On Behalf Of
Stefan Klein
Sent: Wednesday, January 17, 2007 9:32 AM
To: Christoph Palm
Cc: insight-users-***@public.gmane.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

Post by Stefan Klein
Hi Christoph,
I had the same problem and have already entered it in the bug

tracker.

Post by Stefan Klein
http://www.itk.org/Bug/bug.php?op=show&bugid=3689&pos=28
imageReader->SetImageIO( GiplImageIO::New() )
but this is of course not very convenient if you want to

support

Post by Stefan Klein
multiple image formats.
Regards!
Stefan

Post by Christoph Palm
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

Post by Stefan Klein

Post by Christoph Palm
ImageIOFactory, especially with the GDCM image reader. In

fact, the

Post by Stefan Klein

Post by Christoph Palm
imageIOBase was by error assigned to GDCM instead of GIPL.

Then, of

Post by Stefan Klein

Post by Christoph Palm
course, everything seriously went wrong and ended up with

false

Post by Stefan Klein

Post by Christoph Palm
buffer
allocations and a segmentation fault. The wrong assignmed

happend,

Post by Stefan Klein

Post by Christoph Palm
because within the factory all possible reader are tested to

be the

Post by Stefan Klein

Post by Christoph Palm
right one. The first one was rejected, because the filename

was not

Post by Stefan Klein

Post by Christoph Palm
properly. Ok. The second one was the GDCM reader, where no

filename

Post by Stefan Klein

Post by Christoph Palm
testing is applied. In gdcmDocument.cxx, function

CanReadFile

Post by Stefan Klein

Post by Christoph Palm
the first Bytes are read in as Uint16 and tested to be some

numbers.

Post by Stefan Klein

Post by Christoph Palm
If one of these numbers are found, a dicom image without

preample is

Post by Stefan Klein

Post by Christoph Palm
assumed and the function returns true.
Unfortunately, by coincidence obviously my gipl images

showed one of

Post by Stefan Klein

Post by Christoph Palm
these numbers, namely 1, at the beginning of the file. In a

gipl

Post by Stefan Klein

Post by Christoph Palm
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

Post by Stefan Klein

Post by Christoph Palm
4D).
If I change the dimensions to 255 256 1 1, for example,

everything

Post by Stefan Klein

Post by Christoph Palm
is
fine. Now my question: how to solve this in the Insight

framework in

Post by Stefan Klein

Post by Christoph Palm
a
clean way? I am not really familiar with DICOM varieties. Is

it

Post by Stefan Klein

Post by Christoph Palm
possible
to add a fileEnding test to the GDCM reader?
By the way, I also found a bug in writing gipl images. This

is

Post by Stefan Klein

Post by Christoph Palm
already
putted into the BugTracker. Is it possible, that I am the

one and

Post by Stefan Klein

Post by Christoph Palm
only
here who is working with GIPL images? ;-)
Regards
Christoph