Hello, I have created an Google Hangout event, it should be shared with the ITKBarCamp Google+ group if others are interested in attending.
Thanks, Brad On Aug 4, 2014, at 9:36 AM, Nick Tustison <[email protected]> wrote: > 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
