<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<META content="MSHTML 6.00.2800.1276" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=677103113-04102004><FONT face=Verdana color=#0000ff size=2>We
discussed this a while back. You are essentially asking for a constrained
optimization</FONT></SPAN></DIV>
<DIV><SPAN class=677103113-04102004><FONT face=Verdana color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=677103113-04102004> <FONT face=Verdana
color=#0000ff size=2>min F(Image1, Image2, Transform)</FONT></SPAN></DIV>
<DIV><SPAN class=677103113-04102004></SPAN><SPAN
class=677103113-04102004> <FONT face=Verdana color=#0000ff
size=2>s.t. G(Transform) = 0</FONT></SPAN></DIV>
<DIV><SPAN class=677103113-04102004><FONT face=Verdana color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=677103113-04102004><FONT face=Verdana color=#0000ff size=2>All
the image registration in ITK are unconstrained.</FONT></SPAN></DIV>
<DIV><SPAN class=677103113-04102004><FONT face=Verdana color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=677103113-04102004><FONT face=Verdana color=#0000ff size=2>I
think there are two ways to do what you want but you will have to write some
code.</FONT></SPAN></DIV>
<DIV><SPAN class=677103113-04102004><FONT face=Verdana color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=677103113-04102004><FONT face=Verdana color=#0000ff size=2>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 </FONT></SPAN></DIV>
<DIV><SPAN class=677103113-04102004><FONT face=Verdana color=#0000ff size=2>to
wrap a contrained optimization optimizer and develop an API for specifying
constraints. This is probably the best solution
architectually.</FONT></SPAN></DIV>
<DIV><SPAN class=677103113-04102004><FONT face=Verdana color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=677103113-04102004><FONT face=Verdana color=#0000ff size=2>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:</FONT></SPAN></DIV>
<DIV><SPAN class=677103113-04102004><FONT face=Verdana color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=677103113-04102004> <FONT face=Verdana
color=#0000ff size=2>metric = F(Image1, FImage2, Transfrom) + lambda *
G(Transform)</FONT></SPAN></DIV>
<DIV><SPAN class=677103113-04102004><FONT face=Verdana color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=677103113-04102004><FONT face=Verdana color=#0000ff
size=2>where G(Transform) would be zero for angles below a specified
threshold and then increase (linearly?) as the angle exceeds the specified
threshold.</FONT></SPAN></DIV>
<DIV><SPAN class=677103113-04102004><FONT face=Verdana color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=677103113-04102004><FONT face=Verdana color=#0000ff size=2>The
second way requires less code but is architectually fragile.
</FONT></SPAN></DIV>
<DIV><SPAN class=677103113-04102004><FONT face=Verdana color=#0000ff
size=2></FONT></SPAN><SPAN class=677103113-04102004><FONT face=Verdana
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=677103113-04102004><FONT face=Verdana color=#0000ff size=2>For
example, let's take the MeanSquaresImageToImageMetric. The method
GetValue()</FONT></SPAN></DIV>
<DIV><SPAN class=677103113-04102004><FONT face=Verdana color=#0000ff
size=2>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 </FONT></SPAN></DIV>
<DIV><SPAN class=677103113-04102004><FONT face=Verdana color=#0000ff size=2>type
of transformation being used. The metric simply takes the vector of
transformation </FONT></SPAN></DIV>
<DIV><SPAN class=677103113-04102004><FONT face=Verdana color=#0000ff
size=2>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.)</FONT></SPAN></DIV>
<DIV><SPAN class=677103113-04102004><FONT face=Verdana color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=677103113-04102004><FONT face=Verdana color=#0000ff size=2>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.</FONT></SPAN></DIV>
<DIV><SPAN class=677103113-04102004><FONT face=Verdana color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=677103113-04102004><FONT face=Verdana color=#0000ff size=2>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.</FONT></SPAN></DIV>
<DIV><SPAN class=677103113-04102004><FONT face=Verdana color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=677103113-04102004><FONT face=Verdana color=#0000ff size=2>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.</FONT></SPAN></DIV>
<DIV><SPAN class=677103113-04102004><FONT face=Verdana color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=677103113-04102004><FONT face=Verdana color=#0000ff
size=2>Jim</FONT></SPAN></DIV>
<DIV><SPAN class=677103113-04102004><FONT face=Verdana color=#0000ff
size=2></FONT></SPAN> </DIV>
<BLOCKQUOTE>
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma
size=2>-----Original Message-----<BR><B>From:</B> Robert Maroon
[mailto:robertmaroon@yahoo.com]<BR><B>Sent:</B> Friday, October 01, 2004 4:32
PM<BR><B>To:</B> insight-users@itk.org<BR><B>Subject:</B> [Insight-users] How
to limit rotations when registering in ITK?<BR><BR></FONT></DIV>
<DIV>Hi all,</DIV>
<DIV> </DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>Thanks!<BR></DIV>
<DIV>Robert</DIV>
<P>
<HR SIZE=1>
Do you Yahoo!?<BR><A
href="http://us.rd.yahoo.com/mail_us/taglines/security/*http://promotions.yahoo.com/new_mail/static/protection.html">Yahoo!
Mail</A> - You care about security. So do we.</BLOCKQUOTE></BODY></HTML>