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

Mon Aug 4 10:53:00 EDT 2014

what day?
On Aug 4, 2014 10:50 AM, "Bradley Lowekamp" <blowekamp at mail.nih.gov> wrote:

> 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 <ntustison at gmail.com> 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 <blowekamp at mail.nih.gov>
> 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 <ntustison at gmail.com>
> 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 <blowekamp at mail.nih.gov>
> 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 <ntustison at gmail.com>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/community/attachments/20140804/6e0ec8b3/attachment-0002.html>
-------------- next part --------------
_______________________________________________
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