[Insight-developers] ImageIO design and inner workings questions

Kent Williams norman-k-williams@uiowa.edu
Fri, 28 Mar 2003 11:57:32 -0600


By accident I just sent this to Bill Lorenson... so here it is for all of=
=20
youse.

I've noticed a little inconsistency in the setup of the ImageIO classes, =
and

wondered what the 'right' thing to do is in this case:

This came up because of a Purify error: I was calling ImageIO::GetFilenam=
e,=20
then calling a function that called ImageIO::SetFilename. The second=20
SetFileName changed the std::string for m_Filename in ImageIOBase, which=20
invalidated the pointer returned from GetFilename.

The problem was that I'd added calls to CanReadFile to the=20
ReadImageInformation methods, because I'd found that CanReadFile was neve=
r=20
getting called if you explicitly instantiate a particular ImageIO type, a=
s
is=20
done in Testing/Code/IO/itkGEImageIOTest.cxx.  Since the file type, in th=
at=20
case, is never checked, some of my ImageIO classes were getting deep into
the=20
process of reading an Image file before noticing something wrong with the=
=20
ImageHeader.

So CanReadFile (and CanWriteFile) had the side effect of setting the inpu=
t=20
file name, which wasn't hurting anything (except in the case causing the=20
Purify error described above).  I took the call to SetFilename out of all=
 of

my CanReadFile and CanWriteFile methods.

But this now caused the AnalyzeImageIO tests to fail when it went to writ=
e
an=20
Analyze file, because CanWriteFile was the ONLY place that SetFilename wa=
s=20
getting called; consequently AnalyzeImageIO::WriteImageInformation and=20
AnalyzeImageIO::Write both had no filename to work with.

Bottom Line? The m_Filename member of itk::ImageIOBase is being set
correctly=20
before calling the specific ImageIO specialization when reading a file, b=
ut=20
NOT when writing the file.  Unless you set the filename as a side effect =
of=20
the call to CanWriteFile, you can't write the file.

Depending on side effects in member functions to manage the state of an
object=20
doesn't seem like a good design practice.  Either the code that manages a=
nd=20
delegates the various ImageIOBase subclass object needs to make sure that
the=20
filename is set on the subclass object, or we need to figure out some oth=
er=20
way of making sure the filename gets explicitly set somewhere during this=
=20
whole process.