Nick, Would 2pm EST on day this week for you for a google hang out?
Let's plan on review these points I've made along with the notebooks. I'd think the likely output is going to be some initial requirements for a new transform optimizer for composite transforms and the v4 framework. Brad On Aug 1, 2014, at 10:15 AM, Nick Tustison <[email protected]> wrote: > Sorry, Brad, but I'm currently in Salt Lake at a funeral. I'd really like to > understand better so, if you're available, I can do it anytime during the > week on another call. > > Sent from Howling Fantods > >> On Aug 1, 2014, at 7:36 AM, Bradley Lowekamp <[email protected]> wrote: >> >> Nick, >> >> I hope you can make it to today's TCON. I can demo that notebook I linked >> too. It should clarify things. >> >> Brad >> >> On Jul 30, 2014, at 1:57 PM, Nicholas Tustison <[email protected]> wrote: >> >>>> 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
