[Insight-users] How to limit rotations when registering in IT K?

[Miller, James V (Research)]

We discussed this a while back.  You are essentially asking for a
constrained optimization
 
    min F(Image1, Image2, Transform)
    s.t. G(Transform) = 0
 
All the image registration in ITK are unconstrained.
 
I think there are two ways to do what you want but you will have to write
some code.
 
The first way is to modify or create new optimizers. Most the ITK optimizers
are wrappers around vnl optimizers which are wrappers around netlib/lapack
type routines.  We'd need 
to wrap a contrained optimization optimizer and develop an API for
specifying constraints.  This is probably the best solution architectually.
 
The second option is to create a new image metric that incorporates your
contraint.  Here, the metric would incorporate a penalty or additional
"cost" for violating the constraints. The metric would evaluate something
like:
 
    metric = F(Image1, FImage2, Transfrom) + lambda * G(Transform)
 
where G(Transform) would be zero for angles below a specified threshold and
then increase (linearly?) as the angle exceeds the specified threshold.
 
The second way requires less code but is architectually fragile. 
 
For example, let's take the MeanSquaresImageToImageMetric.  The method
GetValue()
takes a set of transformation parameters (vector of parameters) and computes
the mean square difference between the images where one of the images is
transformed using the specified transformation parameters. Unfortunately,
the metric knows nothing about the 
type of transformation being used. The metric simply takes the vector of
transformation 
parameters, and via virtual function call to a transform assigned at
runtime, it passes the transformation parameter vector to the transform.
(This all works in the registration framework because the registration
method will call GetParameters() on the transform and pass them to the
optimizer/metric.  So the parameter vector is implictly consistent between
the transform, metric, and optimizer.)
 
You could subclass the MeanSquaresImageToImageMetric and add in a penalty
term based on the parameter vector passed into routines like GetValue(),
GetValueAndDerivative(), etc. But here you would have to peek into specific
positions in the parameter vector to check the value of the rotation.  This
requires knowlege of the type of transform being used. This is why this
solution is fragile.
 
You could make this less fragile by only allowing your new metric to use a
certain type of transform.  You could override the SetTransform() method in
ImageToImageMetric and check that the specified transform is the type of
transform needed.  Here, you would dynamic cast the pointer to the specified
transform to a the specific type of transform your metric uses (for instance
Rigid3DTransform, etc.).  If the dynamic_cast returns 0, then the wrong type
of transform was specified and you would issue an exception.
 
You could make this less fragile by "deducing" the rotation encapsulated in
the transform by transforming the vertices of a simplex (in the GetValue()
routines) and groking the rotation applied.
 
Jim
 

-----Original Message-----
From: Robert Maroon [mailto:robertmaroon at yahoo.com]
Sent: Friday, October 01, 2004 4:32 PM
To: insight-users at itk.org
Subject: [Insight-users] How to limit rotations when registering in ITK?


Hi all,
 
I am trying to use the ImageRegistration5 example found in the ITK examples
to register a pair of images but I need to restrict the amount of rotation
allowed. I have looked though the examples and documentation and I can't
seem to find a way to constrain the angles (say less than x degrees) in
which the registration can look. I has looking particular to see if there is
anything besides the scaling and MaximumStepLengths that can be set for the
optimizer that might let me acheive this.
 
Thanks!

Robert



  _____  

Do you Yahoo!?
Yahoo!
<http://us.rd.yahoo.com/mail_us/taglines/security/*http://promotions.yahoo.c
om/new_mail/static/protection.html> Mail - You care about security. So do
we.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://public.kitware.com/pipermail/insight-users/attachments/20041004/a2bba9d0/attachment.html