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

[Nick Tustison]

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
>