[Insight-developers] Image output straw man

[mark foskey]

After our discussion on image output on Friday, I thought I should 
propose a design to give people something to think about.

The idea is that calling itk::FooImageIOFactory::RegisterOneFactory() 
would register the factory for both reading and writing.  The issue at 
hand was how the ImageFileWriter would decide which output format to 
use.  I will propose an answer, discussing my rationale between square 
braces, and then raise some potential objections and see if they can be 
dealt with.

Proposed decision algorithm:

Each ImageIO class will have an associated extension string returned by 
FooImageIO::GetExtension().  [If we are going to use filenames to 
indicate format, that information has to be stored with the classes 
that actually do the IO, since people can create more of those classes 
at any time.]

If SetImageIO() has been called for the specified writer, then of 
course the specified output method is used, irrespective of the file 
names.  If one wants to turn off an output method, leaving the method 
unspecified, one would pass a null pointer to SetImageIO().

If there's no specified output format, and there is only one registered 
IO class whose associated extension matches the file name, then that 
class is used.  If there is more than one IO class, or none, then an 
exception is thrown.

There should also be a FooImageIO::SetExtension() method which can 
change the associated extension from the default.  Then, if a 
programmer wants access to somebody else's .pic format, but wants their 
own .pic format to be triggered by the extension, then they can 
register the other format but change its associated extension to an 
empty string or something.  Another refinement would be the ability to 
query for the type of file from which the image is read, so that the 
image can be output to a file of the same type.  That is, there would 
be a GetLastImageIO() method, whose output could be stored and passed 
to SetImageIO() for the writer.

I think all of this provides sensible default behavior, along with a 
straightforward way to deviate from the default.

One might object that format-from-filename inference is an extra layer 
of complexity that isn't really needed.  For command line apps, it's 
the easiest way for the user to specify the desired output format, but 
perhaps we don't expect people to write many command line apps any 
more.  For an output dialog box, we're more likely to want a pull-down 
menu to indicate the desired output format, and programmers are more 
likely to specify the format explicitly.  We should think about how 
often the output file will be specified on the command line.  (If the 
person is involved in an interactive session using ITK wrapped by tcl 
or something, then it might be quite often.)

If we decide not to do format-from-filename, then I now don't see much 
point in having an object factory for output.  I don't see any nicer 
way to explicitly indicate output than, say,

         writer->SetImageIO(itk::PNGImageIO::New());

which we already have.  If that's the way we go, though, then at least 
we should change FooImageIOFactory to FooImageInputFactory to avoid 
enticing users with features we don't offer.

Note also that the idea of a GetLastImageIO() method is independent of 
having an object factory for output; you typically would use only one 
or the other.

I'm sorry this is so long, but I wanted to be thorough.

-- 
Mark Foskey    (919) 843-5436  Computer-Aided Diagnosis and Display Lab
mark_foskey@unc.edu            Department of Radiology, CB 7515, UNC
http://www.cs.unc.edu/~foskey  Chapel Hill, NC  27599-7515