[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.