[Insight-developers] ImageIO design and inner workings questi ons

[Miller, James V (Research)]

Looking at the ImageFileWriter, it looks like the GenerateData()
routine sets the filename on the ImageIO object right before the
the it tells the ImageIO object to write the data.


So I do not understand why the filename was not getting set on the
Analyze ImageIO.

I agree with you that we should rely a method CanReadFile()/CanWriteFile()
to set the file name in the ImageIO object.  I think we should treat
those methods (almost) as static methods (or perhaps const methods) that 
merely answer the question "can I read this file" or "can I write this file"
without modifying the ImageIO. I think that is how the PNGImageIO works.

Jim



> -----Original Message-----
> From: Kent Williams [mailto:kent@mail.psychiatry.uiowa.edu]
> Sent: Friday, March 28, 2003 12:58 PM
> To: Insight Developers List
> Subject: [Insight-developers] ImageIO design and inner workings
> questions
> 
> 
> By accident I just sent this to Bill Lorenson... so here it 
> is for all of 
> 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::GetFilename, 
> then calling a function that called ImageIO::SetFilename. The second 
> SetFileName changed the std::string for m_Filename in 
> ImageIOBase, which 
> invalidated the pointer returned from GetFilename.
> 
> The problem was that I'd added calls to CanReadFile to the 
> ReadImageInformation methods, because I'd found that 
> CanReadFile was never 
> getting called if you explicitly instantiate a particular 
> ImageIO type, as
> is 
> done in Testing/Code/IO/itkGEImageIOTest.cxx.  Since the file 
> type, in that 
> case, is never checked, some of my ImageIO classes were 
> getting deep into
> the 
> process of reading an Image file before noticing something 
> wrong with the 
> ImageHeader.
> 
> So CanReadFile (and CanWriteFile) had the side effect of 
> setting the input 
> file name, which wasn't hurting anything (except in the case 
> causing the 
> 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 write
> an 
> Analyze file, because CanWriteFile was the ONLY place that 
> SetFilename was 
> getting called; consequently 
> AnalyzeImageIO::WriteImageInformation and 
> AnalyzeImageIO::Write both had no filename to work with.
> 
> Bottom Line? The m_Filename member of itk::ImageIOBase is being set
> correctly 
> before calling the specific ImageIO specialization when 
> reading a file, but 
> NOT when writing the file.  Unless you set the filename as a 
> side effect of 
> the call to CanWriteFile, you can't write the file.
> 
> Depending on side effects in member functions to manage the 
> state of an
> object 
> doesn't seem like a good design practice.  Either the code 
> that manages and 
> delegates the various ImageIOBase subclass object needs to 
> make sure that
> the 
> filename is set on the subclass object, or we need to figure 
> out some other 
> way of making sure the filename gets explicitly set somewhere 
> during this 
> whole process.
> _______________________________________________
> Insight-developers mailing list
> Insight-developers@public.kitware.com
> http://public.kitware.com/mailman/listinfo/insight-developers
>