Hi Brad, Yes, 2 pm EST would work for me any day this week.
Nick > On Aug 4, 2014, at 6:13 AM, Bradley Lowekamp <[email protected]> wrote: > > 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
