[Insight-developers] ImageSeriesReader / ImageSeriesWriter

[Luis Ibanez]

Hi Jim,


Yes, the SeriesFileNames connected to the ImageSeriesWriter must
provide the right number of filenames. We just encounter this
situation when making the changes with Mathieu.

Our solution is simple, if the number of filenames provided by
the SeriesFileNames class is different from the number of files
expected by the ImageSeriesWriter then an exception is thrown.

The new API is not mandatory, you can still use the old one
without changes.

The SeriesFileNames classes that are intended to be used here
are smart enough for figuring out the right number of filenames
to produce.

This actually brings up the point that we should modify the
existing NumericSeriesFileNames in order to accept the same
input image as the ImageSeriesWriter and compute the number of
requires filenames. This will also require to inform it about
the image dimension to be used for the output files.

The "mode" in the ImageSeriesWriter is now selected implicity in
the following way:

A) If you don't provide a list of filenames, the Writer
    runs its old API and generates it own list.

B) If you provide the list of filenames, the writer checks
    if the number of filenames matches the expected number,
    and if so, it uses the filenames for writing.


What is important here is to maintain the symmetry of behavior
between the Series Reader and the Series Writer. With the current
changes we keep consistency in the sense that the generation of
filenames is the responsibility of the helper class SeriesFileNames.
There are too many possible schemes for such generation, and it is
convenient to delegate such burden to the helper classes.


Any program using the old API will still compile and run
correctly. We just checked that on the ImageSeriesWriterTest.



    Luis


----------------------------------------
Miller, James V (Research) wrote:

> 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
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers
>