Proposals:TransformIOFactory: Difference between revisions

From KitwarePublic
Jump to navigationJump to search
No edit summary
 
No edit summary
Line 1: Line 1:
itk::TransformFileReader and itk::TransformFileWriter allow an application so save/load transformations from disk.  The IO process converts the transformations to a MetaTransfrom which allows the transform parameters to be serialized in a simple manner.  The file format can contain multiple transformations.
itk::TransformFileReader and itk::TransformFileWriter allow an application so save/load transformations from disk.  The IO process converts the transformations to a MetaTransfrom which allows the transform parameters to be serialized in a simple manner.  The file format can contain multiple transformations. For each transform in the file, the type of transformation is stored along with its parameters.
 
We propose to extend this design to make it more flexible.  Currently, the reader and writer are hardcoded to be able to serialize a known set of transformations.  As such, ITK can only read/write the types of transformations were coded in the reader and writer.  We propose using a TransformFactory to allow any transformation to be read/written in a generic manner.  This will allow a user to add a transformation type to the factory within their application code without having to modify the TransformFileReader and TransformFileWriter.
 
This design leverages the current ITK factory mechanism.  In ITK, there is a master list of registered factories.  Each factory can override the creation of multiple object types.  In the ImageIOFactory mechanism, there is a single factory for each file format.  This allows the ImageFileReader to ask for all factories that can replace an ImageIO object.  The ImageIOFactory then runs through each factory for that replace an ImageIO and queries whether that particular ImageIO can read/write the format.

Revision as of 14:26, 25 March 2005

itk::TransformFileReader and itk::TransformFileWriter allow an application so save/load transformations from disk. The IO process converts the transformations to a MetaTransfrom which allows the transform parameters to be serialized in a simple manner. The file format can contain multiple transformations. For each transform in the file, the type of transformation is stored along with its parameters.

We propose to extend this design to make it more flexible. Currently, the reader and writer are hardcoded to be able to serialize a known set of transformations. As such, ITK can only read/write the types of transformations were coded in the reader and writer. We propose using a TransformFactory to allow any transformation to be read/written in a generic manner. This will allow a user to add a transformation type to the factory within their application code without having to modify the TransformFileReader and TransformFileWriter.

This design leverages the current ITK factory mechanism. In ITK, there is a master list of registered factories. Each factory can override the creation of multiple object types. In the ImageIOFactory mechanism, there is a single factory for each file format. This allows the ImageFileReader to ask for all factories that can replace an ImageIO object. The ImageIOFactory then runs through each factory for that replace an ImageIO and queries whether that particular ImageIO can read/write the format.