Insight Toolkit (ITK) -- Official Repository. ITK builds on a proven, spatially-oriented architecture for processing, segmentation, and registration of scientific images in two, three, or more dimensions.
The documentation for the SpatialObject registration classes correctly state that the spatialobject to image registration framework has a moving spatialobject and a fixed image, but the current names of those classes include ImageToSpatialObjectRegistration and ImageToSpatialObjectMetric which suggest that the image is the moving object and the SpatialObject is the fixed object - which is wrong.
Admittedly, the transform returned by the (Moving)ImageTo(Fixed)Image registration framework is from the fixed image to the moving image whereas the (Moving)SpatialObjectTo(Fixed)Image returns a transform from the moving object to the fixed image; however, the direction of the returned transform should be addressed by documentation while the grammatical interpretation of the class names should be intuitively correct. That is, I propose that grammatical interpretation is more powerful and should be preserved over implementation details (which should be resolved via documentation).
ITK already provides extensive documentation (including in the spatialobject registration classes) which clarifies registration transform directions.
Proposal:
1) Rename the ImageToSpatialObjectRegistration and ImageToSpatialObjectMetric classes to
SpatialObjectToImageRegistration and SpatialObjectToImageMetric classes so that the function of the classes is grammatically correct in the name of the classes - and the history of those classes is preserved.
2) Mark the ImageToSpatialObjectRegistration and ImageToSpatialObjectMetric classes as to-be-deprecated.
3) The documentation in those classes may need some update, but in general it already addresses that the direction of the transform is from the SpatialObject To the image and points out that this is different than the (moving)ImageTo(fixed)image registration framework.
Impact analysis
Existing code will not be impacted beyond receiving the warning that they are using deprecated classes.
New developers will understand the function of the classes from their name - rather than the naming suggested the exact opposite of what actually happens.
Expected behavior
SpatialObjectToImageRegistration or SpatialObjectToImageMetric has a SpatialObject as the moving object and an Image as the fixed structure.
Actual behavior
ImageToSpatialObject registration is interpreted to have an Image as the moving object and a SpatialObject as the fixed object.
Description
The documentation for the SpatialObject registration classes correctly state that the spatialobject to image registration framework has a moving spatialobject and a fixed image, but the current names of those classes include ImageToSpatialObjectRegistration and ImageToSpatialObjectMetric which suggest that the image is the moving object and the SpatialObject is the fixed object - which is wrong.
Admittedly, the transform returned by the (Moving)ImageTo(Fixed)Image registration framework is from the fixed image to the moving image whereas the (Moving)SpatialObjectTo(Fixed)Image returns a transform from the moving object to the fixed image; however, the direction of the returned transform should be addressed by documentation while the grammatical interpretation of the class names should be intuitively correct. That is, I propose that grammatical interpretation is more powerful and should be preserved over implementation details (which should be resolved via documentation).
ITK already provides extensive documentation (including in the spatialobject registration classes) which clarifies registration transform directions.
Proposal:
1) Rename the ImageToSpatialObjectRegistration and ImageToSpatialObjectMetric classes to SpatialObjectToImageRegistration and SpatialObjectToImageMetric classes so that the function of the classes is grammatically correct in the name of the classes - and the history of those classes is preserved.
2) Preserve a copy of the ImageToSpatialObjectRegistration and ImageToSpatialObjectMetric classes per stackoverflow: https://stackoverflow.com/questions/16937359/git-copy-file-preserving-history (Answer 2)
2) Mark the ImageToSpatialObjectRegistration and ImageToSpatialObjectMetric classes as to-be-deprecated.
3) The documentation in those classes may need some update, but in general it already addresses that the direction of the transform is from the SpatialObject To the image and points out that this is different than the (moving)ImageTo(fixed)image registration framework.
Impact analysis
Existing code will not be impacted beyond receiving the warning that they are using deprecated classes.
New developers will understand the function of the classes from their name - rather than the naming suggested the exact opposite of what actually happens.
Expected behavior
SpatialObjectToImageRegistration or SpatialObjectToImageMetric has a SpatialObject as the moving object and an Image as the fixed structure.
Actual behavior
ImageToSpatialObject registration is interpreted to have an Image as the moving object and a SpatialObject as the fixed object.