[Insight-users] Possible bug in ImageFileReader
Luis Ibanez
luis.ibanez@kitware.com
Mon, 17 Mar 2003 22:29:25 -0500
Hi Parag,
Thanks for pointing this out,
You are absolutely right, the ImageIO object should be set
in a specific SetImageIO() method, and only there we should
initializer the m_UserSpecified flag.
Following your suggestion this has been fixed in the code
on the cvs repository. Both in the trunk and in the 1.2
branch.
BTW, you are encouraged to migrate to version 1.2 :-)
Please let us know if you encounter any further problem,
Thanks
Luis
---------------------------
Parag Chandra wrote:
> 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 == 0 ) //try creating via factory
> {
> m_UserSpecified = false;
> m_ImageIO = ImageIOFactory::CreateImageIO(m_FileName.c_str());
> }
> else
> {
> m_UserSpecified = 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 = 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