[Insight-developers] ImageSeriesReader / ImageSeriesWriter

Luis Ibanez luis.ibanez at kitware.com
Mon Jun 7 13:22:32 EDT 2004 

Jim,

I agree with you in that keeping both APIs permanently
will be confusing for future users.

That's the motivation for deprecating the previous API.
Our suggestion is to keep the previous API up to ITK 1.8,
marking it as deprecated. Then, after ITK 1.8 is released,
we could remove the previous API and require users to use
the SeriesFileNames.

The SeriesFileNames classes will know how many filenames
to create in the same way that the ImageSeriesWriter is
computing this right now. That is, by multiplying the last
elements of the size array from the input image region.

--

The SeriesFileNames doesn't actually fit in the pipeline,
this is unrelated to the current changes. In the case of
the reader, the SeriesFileNames is part of the preparations
steps that must be executed before triggering Update() in
the reader.

The new SeriesFileNames should now have a SetInput() or
SetImage() method, in order to access image meta-data.
As a consequence these new SeriesFileNames will be templated
over the image type.


    Luis



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

> I still think having both API's in one class will be confusing to
> the user. This is based on my experience with some of VTK's swiss army
> knife classes.
> 
> 
>>The SeriesFileNames classes that are intended to be used here
>>are smart enough for figuring out the right number of filenames
>>to produce.
> 
> 
> How do the SeriesFileNames know how many filenames to produce for a 
> given image set? How does this fit into the pipeline?
> 
> Jim
> 
> 
> 
> 
> 
> 
> -----Original Message-----
> From: Luis Ibanez [mailto:luis.ibanez at kitware.com]
> Sent: Monday, June 07, 2004 10:37 AM
> To: Miller, James V (Research)
> Cc: 'Mathieu Malaterre'; insight-developers at itk.org; Lorensen, William E
> (Research)
> Subject: Re: [Insight-developers] ImageSeriesReader / ImageSeriesWriter
> 
> 
> 
> 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
>>
> 
> 
> 
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers
>

More information about the Insight-developers mailing list