> 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 _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Kitware offers ITK Training Courses, for more information visit: http://kitware.com/products/protraining.php Please keep messages on-topic and check the ITK FAQ at: http://www.itk.org/Wiki/ITK_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/insight-developers
