[Insight-developers] ImageSeriesReader / ImageSeriesWriter

[Miller, James V (Research)]

Bill and I were just talking about this. Here is the reason the writer was 
set up to default to a numeric series: if you just pass the writer a list of
filenames (as in the ImageSeriesReader), then you need to know how many 
filenames to specify.  The same is true for the ImageSeriesReader but the 
workflow/consequences are different.  In the reader case, presumably a user
is somehow selecting a dataset to operate on. So they are picking files
that exist on disk.  In the writer case, in order for the user to specify
the appropriate set of filenames, the user would need to know precisely how
many images will be produced for a given set of input.  Usually, this is not
too hard but can be difficult is the resolution of the imagery is changing
and 
you can get an extra slice or miss a slice due to truncation/rounding 
(17 slices reduced in resolution by 2, yielding 8 slices).

So what should the appropriate behavior be if the user specifies too few
filenames?  What about too many filenames?

It would be nice, however, from an API standpoint if the SeriesReader and 
SeriesWriter were consistent. 

The idealist in me doesn't like using a "mode" to shoehorn the two
capabilities into the SeriesWriter. I don't like modes in cases where a 
subset of the API is used to specify parameters for one mode and another
subset 
of the API is used to specify parameters for another mode. In this case, the

API for one mode would be Get/SetFileNames(), SetFileName(), AddFileName()
and 
the API for the other mode would be Get/SetSeriesFormat(),
Get/SetStartIndex(), 
Get/SetIncrementIndex().  Presenting the user with all these methods when
they
only need half of them for whatever mode they are using is troubling.

So I think I like having separate classes, ImageSeriesWriter and 
ImageNumericSeriesWriter. Perhaps the ImageNumericSeriesWriter could 
use a NumericSeriesFileNames and a ImageSeriesWriter as its implementation.
I would then change some of the tests/examples to use new ImageSeriesWriter
and some of the tests/examples to use the ImageNumericSeriesWriter.

I am worried about compatibility with such a name change to the current 
ImageSeriesWriter.  It looks like the (working) ImageSeriesWriter was only 
in the 1.6 release (for SPIE?).  But people may be using it and their code
will no longer compile if the current ImageSeriesWriter is supplanted with
a SetFileNames() API. 

Perhaps another name can be used for the ImageSeriesWriter that takes a list
of filenames. Until we come up with a name, I'll refer to it as
Image*SeriesWriter. We could create an (empty) subclass of the current 
ImageSeriesWriter called ImageNumericSeriesWriter which we would use in the 
examples/tests to distinguish it from the use of Image*SeriesWriter.

API changes on the user level IO classes is probably at the top of the list
of things we really have to be careful changing. 

Jim



-----Original Message-----
From: Mathieu Malaterre [mailto:mathieu.malaterre at kitware.com]
Sent: Sunday, June 06, 2004 11:01 PM
To: insight-developers at itk.org
Subject: [Insight-developers] ImageSeriesReader / ImageSeriesWriter


Hi,

   I was looking for a way to write a series of files, with arbitrary
filenames. So I found ImageSeriesWriter, since ImageSeriesReader was doing
what I was looking for. But it seems like this class is more like a
ImageNumericSeriesWriter. 

  I implemented a patch so this class would take an abritrary set of
filenames. My question is then:

- Can I apply this patch (*) ?

- If so I have different options:
   1. Copy the old class to a new class called ImageNumericSeriesWriter
   2. Change all existing tests/example using the old ImageSeriesWriter to
use the new one in combination with a NumericSeriesFileNames
   3. Try to maintain some sort of compatibility mode.

My prefered approach is 2, it shows users how flexible the SeriesWriter are.

Comments suggestions welcome,
Mathieu
(*) I am having currently some problems generating patches since the backup
of last week. It seems to have change files date&time on the cvs repository
and thus to use the included patch to this email, one need to do:

   patch -p1 < series.patch
           ^
Mathieu