[ITK-dev] [ITK] Optimizing composite transforms and center of transform

[Nicholas Tustison]

> To try to summaries... sorry if have not been clear enough in my explanations.

No, I blame me—I’m consistently distracted by the scenery outside here in
California and it’s definitely affecting my ability to concentrate on code
questions.

> INITIAL QUESTION
> 
> How does composite transform and the "Center" parameter interact? How does this relate to the virtual domain?

The composite transform is agnostic with respect to whether or not a 
transform has a center or any other fixed parameter set.  The only
distinction we make is typology with respect to linear/deformable. To 
be clear, we’re not discussing any of the  “Centered” transforms:

* CenteredAffineTransform
* CenteredEuler3DTransform
* CenteredEuler2DTransform
* CenteredSimilarity2DTransform

None of those transforms are used in ANTs but I don’t think 
their optimization would be an issue in the new ITKv4 registration 
framework.

The virtual domain is simply defined in terms of standard image 
geometry (origin, spacing, etc.) and is currently set in terms of the 
fixed image geometry.  

> MY UNDERSTANDING
> 
> 1) Using a "Center" initialized transform only works correctly for a single transform and directly with a composite. ( This is with the current center initializers, a different approach could be done which takes into consideration the composition )

I don’t see why it would only work correctly for a single transform.  Suppose
I optimize a translation transform to get it’s optimal parameters for a given
registration problem.  It’s not clear to me why it would be a problem to follow
that with optimizing an Euler3D transform (which we do all the time in ANTs).  
Obviously, we have to specify a staring point for the second transform (which
is identity by default) and perhaps it would be better to have a different 
starting point but I don’t see why starting with the default parameters is a 
problem.

If the “Center initialized transform” is one of the transforms listed above 
then we don’t use those.  If it’s simply the result of using the 
CenteredTransformInitializer, then we just pull the itk::TranslationTransform 
part from the result and push that translation transform into the composite 
transform queue.   I don’t see why it would be a problem to then optimize, 
for example, the Euler3DTransform which just has 3 translation parameters 
and 3 angle parameters to optimize where the center is implicitly defined 
(unlike the CenteredEuler3DTransform which does have additional Center 
parameters).  

> 2) The virtual domain should be initialized such that the two images "Center"s are at the origin. This an alternative to using the "Center" transform parameters, and better works with composite transforms.

Yes, that would probably be a better initialization but I don’t know why it would
be a problem for the current framework to optimize with the origin elsewhere.
Right now, each transform within the composite transform queue is 
optimized starting from its identity parameters but perhaps the initializer
idea that you propose would improve optimization. 

> I was not aware that 2 was the best practice with the ITKv4 framework. Do we have any examples/test/documentation to indicate this?  Further more using the current CenterTransformInitalizers to initialize the virtual domain is not readily apparent[1] how to map the parameters.
> PROPOSAL
> 
> Perhaps we need a new Initializer filter to assist with initializing the virtual domain to initialize this practice? 
> 
> Brad