[Insight-users] Possible bug in ImageFileReader
Parag Chandra
pchandra@radonc.unc.edu
Mon, 17 Mar 2003 15:23:06 -0500
This is a multi-part message in MIME format.
------=_NextPart_000_0049_01C2EC99.1BF6B660
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
I've noticed that a given ImageFileReader won't correctly read more than =
one type of image. I've traced this to the following block of code =
inside GenerateOutputInformation():
if ( m_ImageIO =3D=3D 0 ) //try creating via factory
{
m_UserSpecified =3D false;
m_ImageIO =3D ImageIOFactory::CreateImageIO(m_FileName.c_str());
}
else
{
m_UserSpecified =3D true;
}
The first time the ImageFileReader tries to read an image, there will be =
no m_ImageIO set, so it will try to use the object factory mechanism to =
instantiate the correct ImageIO. The next time around, it will see that =
an m_ImageIO has already been set, so it will incorrectly assume that =
the user must have explicitly provided an ImageIO, and it will then try =
to use this to read an image that could potentially be in a completely =
different format. I've gotten around this limitation in my app by =
explicitly calling ImageFileReader->SetImageIO(NULL) each time before I =
try to read an image, but I think a better way would be to rewrite =
SetImageIO() so that it is no longer an itkSetObjectMacro. It should do =
everything that itkSetObjectMacro would do, but additionally, set =
m_UserSpecified =3D true. Then the above block of code should be =
modified so that the else clause is removed.
Of course, maybe this has all been fixed in v1.2; I'm still using 1.0. =
Thanks for looking into this anyway.
Best regards,
-Parag Chandra
------=_NextPart_000_0049_01C2EC99.1BF6B660
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1141" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>I've noticed that a given =
ImageFileReader won't=20
correctly read more than one type of image. I've traced this to the =
following=20
block of code inside GenerateOutputInformation():</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2> if ( m_ImageIO =3D=3D 0 ) //try =
creating via=20
factory<BR> {<BR> m_UserSpecified =
=3D=20
false;<BR> m_ImageIO =3D=20
ImageIOFactory::CreateImageIO(m_FileName.c_str());<BR> =
}<BR> else<BR> {<BR> =
m_UserSpecified =3D=20
true;<BR> }<BR></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>The first time the ImageFileReader =
tries to read an=20
image, there will be no m_ImageIO set, so it will try to use the object =
factory=20
mechanism to instantiate the correct ImageIO. The next time around, it =
will see=20
that an m_ImageIO has already been set, so it will incorrectly assume =
that the=20
user must have explicitly provided an ImageIO, and it will then try to =
use this=20
to read an image that could potentially be in a completely different =
format.=20
I've gotten around this limitation in my app by explicitly calling=20
ImageFileReader->SetImageIO(NULL) each time before I try to read an =
image,=20
but I think a better way would be to rewrite SetImageIO() so that it is =
no=20
longer an itkSetObjectMacro. It should do everything that =
itkSetObjectMacro=20
would do, but additionally, set m_UserSpecified =3D true. Then the above =
block of=20
code should be modified so that the else clause is removed.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial><FONT size=3D2>Of course, maybe this has all =
been fixed in=20
v1.2; I'm still using 1.0. Thanks for looking into this=20
anyway.</FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT size=3D2></FONT></FONT> </DIV>
<DIV><FONT face=3DArial><FONT size=3D2>Best regards,</FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT size=3D2>-Parag=20
Chandra</FONT></DIV></FONT></BODY></HTML>
------=_NextPart_000_0049_01C2EC99.1BF6B660--