[Insight-developers] ImageSeries Reader / Writer

[Will Schroeder]

Hi Folks-

I wanted to give you a heads up on a set of classes that I'm starting to 
check in. The work is in progress and will likely continue until the end of 
the month (since I'm on vacation in the middle there). But enough of the 
framework will be checked in today so that you can see where things are 
heading and provide feedback on Friday's TCon.

The ImageSeriesReader / ImageSeriesWriter are like ImageFileReader and 
ImageFileWriter except that they read/write sequences of files. Like the 
ImageFileReader and ImageFileWriter they can use the ImageIO factory 
mechanism to determine the correct ImageIO subclass (ie, file format) to 
use. However, the ImageSeriesReader/Writer also use another helper class, a 
FileIteratorBase, to construct the names of the sequence of files to 
read/write. The FileIteratorBase can be specified manually, or as is more 
typical, the ImageIO class now provides the preferred FileIteratorBase 
subclass to use to create the sequence of filenames. Why? Because some 
sequences like PNG will typically create numeric sequences like junk.1.png, 
junk.2.png, etc. whereas DICOM series may be some weird set of filenames, 
and a DICOMSeriesFileIterator would provide the sequence in the correct 
order. Right now FileIteratorBase and NumericSeriesFileIterator are the 
only two file iterators created. We'll want to add more for the DICOM 
ImageIO and possibly some others.

I've had to rework some of the ImageIO infrastructure; in particular I 
added the methods NewFileIterator() and SupportsDimension(unsigned long 
dim) as described below.

   /** The file iterator interfaces with the ImageSeriesReader
    * and ImageSeriesWriter to read and write multiple files. The
    * subclasses of ImageIOBase create and return the correct type
    * of file iterator to use. */
   virtual FileIteratorBase* NewFileIterator();

   /** The different types of ImageIO's can support data of varying
    * dimensionality. For example, some file formats are strictly 2D
    * while others can support 2D, 3D, or even n-D. This method returns
    * true/false as to whether the ImageIO can support the dimension
    * indicated. */
   virtual bool SupportsDimension(unsigned long dim)
     {return (dim == 2);}

There is a test Testing/Code/IO/itkImageSeriesIOTest.cxx that will give you 
an idea of how it fits together.

I am going to be checking in this work over the course of the day as I 
continue to test the classes and the modifications to existing classes. For 
those with a vested interest in the IO infrastructure I'd like you to take 
a peek and provide some feedback prior to finalizing the design and 
implementation.

Final note: the ImageSeriesWriter maps an n-D image into a series of m-D 
(typically 2D) slices. For convenience this requires modifying the Index 
class to that I can increment the Index and have it "wrap / modulo / cycle" 
like a clock does (incrementing slices, then volumes, etc.) As far as I can 
tell there is nothing like this in Index currently. Can I add it? I'd like 
to call it something like "AddBasisIndex" to be consistent with the 
existing GetBasisIndex. Comments?

Will