[Insight-developers] changes to MI registration

Luis Ibanez luis.ibanez@kitware.com
Wed, 06 Mar 2002 18:53:11 -0500


Lydia,

I agree with you in that it is a shame to have the documentation
relegated to the tests.

 In one hand, Doxygen will not parse it at all. On the other hand,
it will be pretty hard to figure out where to find it.

We plan to have at some point at least 60 files more  for 
RegistrationMethodsTests
and it is very unlikely that somebody will remember that 
"RegistrationMethodTest_13 "
is the MutualInformation implementation corresponding to the Viola-Wells 
paper.

There is also the fact that even though the methods look similar, there 
is a lot
of "magic" on setting their parameters right. A specific class, as you 
said can
promote this parameter setting at the API level.

How about going back to having a class named    
itk::ViolaWellsRegistationMethod ?

I know that this is how it was at the very beginning and that it looks 
like taking
the largerst path to go to the original place... but between

   "ViolaWellsRegistrationMethod" being in Code/Algorithms

 and    

   "RegistrationMethodTest_13" being in Testing/Code/Algorithms

I largely will prefer the first.

The othe registration methods so far are not so specific.  They represent
combinatorial combinations of the components; so having them numbered
seems to be ok.


There should be some limits to borg-assimilations...


Luis.




=======================================

Lydia Ng wrote:

>Why:
>====
>As per Kitware/GE code review, registration was to change
>so that registration components can be connected at run-time
>instead of being compile-time template parameters.
>
>As such, all registration components were to de-templated
>and all ImageToImageXXXXXRegistration classes are to be
>replaced by one generic ImageRegistrationMethod class.
>
>
>Changes:
>========
>Registration components (metric,optimizer,transform) has
>been now de-templated.
>
>Previously, exisiting MI registration classes
>ImageToImageAffineMutualInformationGradientDescentRegistration
>ImageToImageRigidMutualInformationGradientDescentRegistration
>are now defunct and will be removed.
>
>The upshot is that if you want to use MI registration 
>with those combination of components you have to connect
>them up yourself.
>
>Tests ImageRegistrationMethodTest_13 and
>ImageRegistrationMethodTest_14 
>are examples how to use the new framework to get back the 
>same functionality that were previously provided by the above
>MI registration classes.
>
>It seems such a pity to lose the docs I had with MI
>registration classes - I've moved them into the test files.
>
>
>- Lydia
>
>
>
> 
>_______________________________________________
>Insight-developers mailing list
>Insight-developers@public.kitware.com
>http://public.kitware.com/mailman/listinfo/insight-developers
>